5735 - go parser shadow tables#5832
Conversation
| "user": models.ForeignKey( | ||
| "users.User", | ||
| on_delete=models.CASCADE, | ||
| related_name="+", |
There was a problem hiding this comment.
related_name="+" disables the reverse relationship, so you cannot access user.shadow_data_files like you can user.data_files - can change this if necessary - Django docs
| from django.db import models | ||
|
|
||
|
|
||
| def create_shadow_model( |
There was a problem hiding this comment.
subclassing the "production" model (TANF_T1 for example) actually creates a model with a foreign key pointer/relationship to the parent model, rather than copying the model fields into the new model. this helper copies all the fields and relationships, but doesn't preserve the @property methods. Since we're not using the python properties on the go side, i think that's okay, but something to be aware of - the shadow models are more limited.
|
|
||
| dump-parser-schema: | ||
| desc: Dump selected parser table CREATE TABLE statements to schema-tmp.sql | ||
| desc: Dump selected parser table CREATE TABLE statements to parser schema.sql, using GO_PARSER_SHADOW_MODE to select shadow or production tables |
There was a problem hiding this comment.
kinda torn on this change (along with the generated schema.sql, query.sql, query.sql.go, and models.go). we don't really use any of these, it's more of a gut-check that changes to the python models have been appropriately represented in the go schemas. i don't know if that should check the shadow tables or not. the task switches based on the GO_PARSER_SHADOW_MODE flag, but the generated files are all shadow-specific. if it's not useful, i can revert it
There was a problem hiding this comment.
- keep original schema.sql versioned
- unversion models.go
- change task to dump to schema.temp.sql for sqlc diff
- generate models.go and models.temp.go for sqlc diff
There was a problem hiding this comment.
more helpful to validate against schema yml definition and storage/writer/tanf|ssp|tribal record serializers (still two steps) - generate serializer based on yml file?
define parsedrecord as an interface (look at decoders/decoder.go and decoder/csv.go), put serializer on validationresult telling each record how to serialize itself
separate ticket?
There was a problem hiding this comment.
Did we write a ticket up to tighten up our django migration validation against the Go schemas yet?
| current_app.send_task( | ||
| GO_PARSER_TASK_NAME, | ||
| args=[data_file_id], | ||
| queue=GO_PARSER_QUEUE, |
|
|
||
| var df DataFilesDatafile | ||
| var df ShadowDataFilesDatafile | ||
| err := pool.QueryRow(ctx, query, id).Scan( |
There was a problem hiding this comment.
look into easier way to map the struct
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5832 +/- ##
===========================================
+ Coverage 93.98% 94.02% +0.04%
===========================================
Files 538 543 +5
Lines 24618 24776 +158
Branches 620 620
===========================================
+ Hits 23137 23296 +159
+ Misses 1368 1367 -1
Partials 113 113
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
|
||
| summaryStatusAccepted = "Accepted" | ||
| summaryStatusAcceptedWithErrors = "Accepted with Errors" | ||
| summaryStatusPartiallyAccepted = "Partially Accepted" |
There was a problem hiding this comment.
Go uses "Partially Accepted" while Django enum is "Partially Accepted with Errors", will this cause any problem?
There was a problem hiding this comment.
I believe "Partially Accepted with Errors" is the friendly/detail name, but the enum/db value is Partially Accepted. You can see it encoded in this way in the original migration
('Partially Accepted with Errors', 'Partially Accepted')
There was a problem hiding this comment.
These statuses can largely be removed right? The go parser will only ever need to set a rejected status based on specific validation/exceptions right?
| if err != nil { | ||
| return fmt.Errorf("update %s result for datafile_id=%d: %w", tableName, datafileID, err) | ||
| } | ||
| totalCreatedInt4, err := int64ToInt4(totalCreated) |
There was a problem hiding this comment.
Why do we need the conversion? Seems like we should just let the "total" counts be int32 to prevent the extra conversion steps. Do the compiled queries require the pgtype or can we give it the exact Go int32 and let the DB engine handle the conversion if needed?
There was a problem hiding this comment.
i think this is because sqlc generated the queries for a nullable integer column, which is pgtype.Int4. if the field was NOT NULL then it would generate an int32 and we wouldn't have to convert. there's a sqlc config option emit_pointers_for_null_types which might handle this, but i didn't test it out
There was a problem hiding this comment.
Hmm, that is a nice override. Might save our code from any conversions in the future and push it off to the library or db engine. Will you write up an exploratory snack ticket for this?
Co-authored-by: Eric Lipe <125676261+elipe17@users.noreply.github.com>
elipe17
left a comment
There was a problem hiding this comment.
Two requests for tickets, otherwise LGTM!
…5735-go-parser-shadow-tables
…t-tech/TANF-app into 5735-go-parser-shadow-tables
Summary of Changes
Pull request closes #5735
GO_PARSER_SHADOW_MODEenvironment variable istrue. This var defaults totrueGO_PARSER_SHADOW_MODE=false, the go parser writes to the production parser tablesGO_PARSER_SHADOW_MODE=true)statusand record count update for the shadow datafile (and production df when the var is false)How to Test
GO_PARSER_SHADOW_MODE=Truein your backend.env, then start the servicesdatafile/datafilesummarydata to the production tablesGO_PARSER_SHADOW_MODEtoFalse.docker compose stop celeryto avoid this). *The go parser writes to the samedatafileanddatafilesummaryrow, this causes some issues in the frontend (nocase_aggregatesare written because it has not yet been implemented)*Deliverables
More details on how deliverables herein are assessed included here.
Deliverable 1: Accepted Features
Checklist of ACs:
lfrohlichand/oradpenningtonconfirmed that ACs are met.Deliverable 2: Tested Code
CodeCov Reportcomment in PR)CodeCov Reportcomment in PR)Deliverable 3: Properly Styled Code
Deliverable 4: Accessible
iamjollyandttran-hubusing Accessibility Insights reveal any errors introduced in this PR?Deliverable 5: Deployed
Deliverable 6: Documented
Deliverable 7: Secure
Deliverable 8: User Research
Research product(s) clearly articulate(s):