Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Add strong typing to document creation #2161

Conversation

fredcarle
Copy link
Collaborator

@fredcarle fredcarle commented Jan 2, 2024

Relevant issue(s)

Resolves #935
Resolves #1703

Description

This PR adds strong document typing to document creation by using the field descriptions to determine Go types. Datetime is now properly supported and formatting is enforced.

Note that a lot of docIDs have changed as a result of this refactor.

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

make test

Specify the platform(s) on which this was tested:

  • MacOS

@fredcarle fredcarle added the refactor This issue specific to or requires *notable* refactoring of existing codebases and components label Jan 2, 2024
@fredcarle fredcarle added this to the DefraDB v0.9 milestone Jan 2, 2024
@fredcarle fredcarle requested a review from a team January 2, 2024 22:43
@fredcarle fredcarle self-assigned this Jan 2, 2024
@fredcarle fredcarle force-pushed the fredcarle/refactor/document-strong-typing branch from 56e6c2f to 709909e Compare January 2, 2024 22:45
Copy link

codecov bot commented Jan 2, 2024

Codecov Report

Attention: 77 lines in your changes are missing coverage. Please review.

Comparison is base (9da4dab) 74.35% compared to head (30f2e6a) 74.10%.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #2161      +/-   ##
===========================================
- Coverage    74.35%   74.10%   -0.25%     
===========================================
  Files          252      252              
  Lines        25217    25242      +25     
===========================================
- Hits         18749    18704      -45     
- Misses        5184     5255      +71     
+ Partials      1284     1283       -1     
Flag Coverage Δ
all-tests 74.10% <74.33%> (-0.25%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
client/errors.go 56.86% <100.00%> (+1.76%) ⬆️
core/encoding.go 64.23% <100.00%> (-0.48%) ⬇️
db/backup.go 59.64% <100.00%> (+1.07%) ⬆️
db/collection.go 69.12% <ø> (-0.83%) ⬇️
db/collection_get.go 72.22% <100.00%> (ø)
db/collection_index.go 92.66% <100.00%> (ø)
db/errors.go 68.15% <ø> (-1.58%) ⬇️
db/fetcher/encoded_doc.go 76.14% <100.00%> (-1.28%) ⬇️
http/client_collection.go 35.25% <100.00%> (-0.37%) ⬇️
http/handler_collection.go 60.35% <100.00%> (ø)
... and 5 more

... and 16 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9da4dab...30f2e6a. Read the comment docs.

client/document.go Outdated Show resolved Hide resolved
Copy link
Member

@nasdf nasdf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work Fred!

client/document.go Show resolved Hide resolved
client/document.go Outdated Show resolved Hide resolved
client/document.go Outdated Show resolved Hide resolved
client/document.go Outdated Show resolved Hide resolved
@fredcarle fredcarle force-pushed the fredcarle/refactor/document-strong-typing branch from 06aee19 to 39b7b30 Compare January 3, 2024 23:27
@fredcarle fredcarle requested review from nasdf, AndrewSisley and a team January 4, 2024 15:02
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just have a few small questions/todos for you :)

cli/collection_create.go Show resolved Hide resolved
client/document.go Show resolved Hide resolved
}

docs := make([]*Document, len(a))
for _, v := range a {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: I would suggest refactoring this block (single doc jsonObj) with NewDocFromJSON so that they both use exactly the same logic. It feels like it would be more maintainable, and it feels strange that they are not doing so.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not really practical to do so since here we already have a fastjson.Object and not a []byte

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You would probably want to change NewDocFromJSON to create a fastjson.Object and pass that into the shared code.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They already share setWithFastJSONObject found within SetWithJSON. I don't think it would simplify anything.

client/document.go Show resolved Hide resolved
@@ -61,31 +75,31 @@ func TestNewFromJSON(t *testing.T) {
assert.Equal(t, doc.fields["Name"].Type(), LWW_REGISTER)
assert.Equal(t, doc.fields["Age"].Name(), "Age")
assert.Equal(t, doc.fields["Age"].Type(), LWW_REGISTER)
assert.Equal(t, doc.fields["Address"].Name(), "Address")
assert.Equal(t, doc.fields["Address"].Type(), OBJECT)
// assert.Equal(t, doc.fields["Address"].Name(), "Address")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: Why are these commented out? Please either document why, or put them back :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because in develop it used to create a doc with a sub object which we currently don't support. I should probably just remove the commented code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see my bad :) Thanks for removing them

db/collection.go Outdated Show resolved Hide resolved
db/collection_update.go Show resolved Hide resolved
@@ -1352,7 +1352,7 @@ func TestAutoGenerate_IfColDefinitionsAreValid_ShouldGenerate(t *testing.T) {
Kind: client.FieldKind_STRING,
},
{
Name: "owner",
Name: "owner_id",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: This change seems wrong, and I can't spot anything in the PR description. Why has this changed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internally the relationship is set on owner_id and not owner. For this test to work properly it has to be owner_id.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit confused about this one too

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we define a schema, in the SDL only owner would be defined but internally we also define owner_id and this is the field that hold the foreign docID. For this test, the code will look specifically for owner_id to set the foreign docID to. It previously worked before but was accidental and probably a bug.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is correct though - Kind is client.FieldKind_FOREIGN_OBJECT, but foo_id fields should be of kind INTERNAL_ID IIRC

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed it to be representative of what it would be.

{
	Name:         "owner_id",
	Kind:         client.FieldKind_DocKey,
	RelationType: client.Relation_Type_INTERNAL_ID,
}

client/document_test.go Outdated Show resolved Hide resolved
client/document_test.go Outdated Show resolved Hide resolved
client/document_test.go Outdated Show resolved Hide resolved
client/document_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - Thanks a bunch Fred :)

I mentioned this to Shahzad - his rename PR seemed to touch a lot of the lines that this PR does, strongly suggest checking in with him before merging if you guys haven't already.

@fredcarle
Copy link
Collaborator Author

LGTM - Thanks a bunch Fred :)

I mentioned this to Shahzad - his rename PR seemed to touch a lot of the lines that this PR does, strongly suggest checking in with him before merging if you guys haven't already.

Thanks Andy! And yes we have discussed it. He will merge first :)

@fredcarle fredcarle force-pushed the fredcarle/refactor/document-strong-typing branch from 1b8d13f to 6da093a Compare January 5, 2024 14:09
@fredcarle fredcarle force-pushed the fredcarle/refactor/document-strong-typing branch from 6da093a to 30f2e6a Compare January 5, 2024 14:49
@fredcarle fredcarle merged commit 0c1c4fe into sourcenetwork:develop Jan 5, 2024
30 of 31 checks passed
@fredcarle fredcarle deleted the fredcarle/refactor/document-strong-typing branch January 5, 2024 15:12
shahzadlone pushed a commit to shahzadlone/defradb that referenced this pull request Jan 22, 2024
## Relevant issue(s)

Resolves sourcenetwork#935 
Resolves sourcenetwork#1703 

## Description

This PR adds strong document typing to document creation by using the
field descriptions to determine Go types. Datetime is now properly
supported and formatting is enforced.

Note that a lot of docIDs have changed as a result of this refactor.
shahzadlone pushed a commit to shahzadlone/defradb that referenced this pull request Feb 23, 2024
## Relevant issue(s)

Resolves sourcenetwork#935 
Resolves sourcenetwork#1703 

## Description

This PR adds strong document typing to document creation by using the
field descriptions to determine Go types. Datetime is now properly
supported and formatting is enforced.

Note that a lot of docIDs have changed as a result of this refactor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor This issue specific to or requires *notable* refactoring of existing codebases and components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Field alias does not exist in some cases for update of one-one Document serialization needs strong typing
4 participants