Skip to content
This repository was archived by the owner on Sep 3, 2021. It is now read-only.

Fixes: merging interface type nodes / using interfaces with no scalars #365

Merged
merged 11 commits into from
Dec 22, 2019
Merged

Fixes: merging interface type nodes / using interfaces with no scalars #365

merged 11 commits into from
Dec 22, 2019

Conversation

michaeldgraham
Copy link
Collaborator

This PR contains a few fixes:

Issue #361 Merge node should add interface label

This issue / inconsistency occurs when a merge node operation creates a node. I realized after the initial PR for merge operations that we should implement the same behavior that the node creation mutation has when the node is an object type implementing an interface - the node recieves both the label of its type and the label of the implemented interface.

Issue #349 Interfaces with no scalar fields generate invalid schemas

This issue concerns the ordering enum type, and corresponding orderBy field arguments, being generated for a node type even when that type does not contain at least 1 property type field which could be used for ordering (scalar, temporal, etc.). This issue is avoided when a node is represented by an object type definition, as in such cases we guarantee the existence of at least 1 field - the _id field. But when an interface definition represents a node, we do not currently generate an _id field for it, so it opened up the possibility of generating and trying to use an empty ordering enum, built for an interface type with no fields appropriate for ordering.

This raises the question of whether we should add the _id field to interfaces representing nodes. If we were to do that, it seems we would also need add the _id field to all object types implementing that interface.

To resolve this issue for now, the generation of an ordering enum for an object or interface node type, and any field arguments that use it, is now conditional on that node type having at least 1 property type field.

Upstream merge
used in checking that a given node type definition has at least one property type field (scalar, temporal, etc.), as when it does not, an ordering enum is not generated
conditionally generates the arguments and enum definition used for ordering a given node type, by checking for whether that type has at least 1 orderable field
when at the Query type, augmentNodeTypeFields now blocks initialization of the ast for generated ordering and filtering types, as they are never used (e.g., _QueryOrdering, etc.)
similar to what's done with nodeCreate
tests an edge case for when the user has provided their own enum and field arguments using it, but it would not have been generated and would not be successfully translated. Despite this, it should probably persist~
@codecov-io
Copy link

codecov-io commented Dec 21, 2019

Codecov Report

Merging #365 into master will increase coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #365      +/-   ##
==========================================
+ Coverage   96.31%   96.34%   +0.02%     
==========================================
  Files          24       24              
  Lines        2821     2842      +21     
==========================================
+ Hits         2717     2738      +21     
  Misses        104      104
Impacted Files Coverage Δ
src/augment/types/relationship/relationship.js 100% <ø> (ø) ⬆️
src/index.js 71.87% <ø> (ø) ⬆️
src/utils.js 93.55% <100%> (+0.01%) ⬆️
src/augment/input-values.js 100% <100%> (ø) ⬆️
src/augment/fields.js 100% <100%> (ø) ⬆️
src/augment/types/node/query.js 100% <100%> (ø) ⬆️
src/augment/types/node/node.js 100% <100%> (ø) ⬆️
src/translate.js 98.31% <100%> (ø) ⬆️

Continue to review full report at Codecov.

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

@johnymontana
Copy link
Contributor

Looks good. I think we do not want to add the _id field to the interface type during schema augmentation since there may be some cases where an implementing type of that interface is resolved from a data layer outside of Neo4j and we don't want to force the _id to be implmented in that case.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants