-
Notifications
You must be signed in to change notification settings - Fork 51
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
feat: Default scalar field values #2997
feat: Default scalar field values #2997
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2997 +/- ##
===========================================
- Coverage 79.46% 79.40% -0.06%
===========================================
Files 329 329
Lines 25133 25225 +92
===========================================
+ Hits 19971 20029 +58
- Misses 3750 3772 +22
- Partials 1412 1424 +12
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 12 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good and is easy to read, but please add some error tests, validation for the default values (in definition_validation.go), View behaviour, and either test PatchCollection works, or temporary block it off (and test that).
) (any, error) { | ||
astNamed, ok := field.Type.(*ast.Named) | ||
if !ok { | ||
return nil, NewErrDefaultValueNotAllowed(field.Name.Value, field.Type.String()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: Please add tests for this error condition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
var value any | ||
for _, arg := range directive.Arguments { | ||
if defaultPropNameToType[arg.Name.Value] != astNamed.Name.Value { | ||
return nil, NewErrDefaultValueInvalid(astNamed.Name.Value, arg.Name.Value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: Please add tests for this error condition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -38,6 +38,9 @@ type CollectionFieldDescription struct { | |||
// | |||
// Otherwise will be [None]. | |||
RelationName immutable.Option[string] | |||
|
|||
// DefaultValue contains the default value for this field. | |||
DefaultValue any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: Please test the PatchCollection behaviour for this new property
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -38,6 +38,9 @@ type CollectionFieldDescription struct { | |||
// | |||
// Otherwise will be [None]. | |||
RelationName immutable.Option[string] | |||
|
|||
// DefaultValue contains the default value for this field. | |||
DefaultValue any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: Please test and document what happens when this is set on a View - and consider adding a validation rule to prevent that (as it makes no sense to me) (and test that, including on Patch).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a test to show the current behavior. Since it has no effect on the results of the view, I think allowing it is better than having the schema definition and view definition languages diverge and have slightly different rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay cheers, I'm happy with that :) - can you please document that the property is ignored for views on the directive, and on this CollectionFieldDescription
prop so that users know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
const ( | ||
typeID string = "ID" | ||
typeBoolean string = "Boolean" | ||
typeInt string = "Int" | ||
typeFloat string = "Float" | ||
typeDateTime string = "DateTime" | ||
typeString string = "String" | ||
typeBlob string = "Blob" | ||
typeJSON string = "JSON" | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: Thanks for moving
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cheers thanks for adding the requested tests
`, | ||
}, | ||
testUtils.Request{ | ||
Request: `mutation { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Would it be worth using the CreateDoc
action instead to test across all clients?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This applies to all the integration tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please use the CreateDoc action instead Keenan (nice spot Fred)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for all the tests. Lets just resolve my question before merging please.
Description: "Simple create mutation, with default value, no value provided, and created twice", | ||
SupportedMutationTypes: immutable.Some([]testUtils.MutationType{ | ||
// This test will fail if using the collection save | ||
// method because it does not create two unique docs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I can't spot anything super obvious in the test code as to why Save
would not work, would you mind expanding a little?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like calling save does not actually create two unique documents when the fields have the same value. I'm guessing it checks if the docID exists and calls update instead of create.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh true - it does - thanks Keenan. Might be worth adding that to this code-comment then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks Keenan :)
Bug bash result: #3133 |
Relevant issue(s)
Resolves #2952
Description
This PR adds support for default field values using a new
@default
directive.Tasks
How has this been tested?
Added integration tests
Specify the platform(s) on which this was tested: