-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
DataStore cannot find ID field of connected record #8285
Comments
It would appear that I have to manually add the following code to the schema.js file then it works fine. Problem is that I have 165 connections like this - that is 165 manual entries every time I change the model. Can amplify codegen models just include this field?
|
Further discovery here. I have two connections like this in my schema.graphql
In the schema.js that is generated by amplify codegen models it generates an association with connectionType as follows for the above two connections: If the connectionType is "BELONGS_TO" then "characteristicValuePlantId" field is not created. But if the connectionType is "HAS_ONE" then the "characteristicValueUomId" field is created. I can't see why one would be created as BELONGS_TO versus HAS_ONE and why BELONGS_TO is not creating the id field like HAS_ONE is doing. |
Hey @sacrampton , in your issue description there seems to be a typo, so I just want to clarify. type Asset @model {
id: ID
assetPlantId: ID
plant: Plant @connection(fields: ["assetPlantId"])
} I get the following generated schema for the model ( "Asset":{
"name":"Asset",
"fields":{
"id":{
"name":"id",
"isArray":false,
"type":"ID",
"isRequired":true,
"attributes":[
]
},
"assetPlantId":{
"name":"assetPlantId",
"isArray":false,
"type":"ID",
"isRequired":false,
"attributes":[
]
},
"plant":{
"name":"plant",
"isArray":false,
"type":{
"model":"Plant"
},
"isRequired":false,
"attributes":[
],
"association":{
"connectionType":"HAS_ONE",
"associatedWith":"id",
"targetName":"assetPlantId"
}
}
},
"syncable":true,
"pluralName":"Assets",
"attributes":[
{
"type":"model",
"properties":{
}
}
]
} |
I'd also make sure that you're using a recent version of the Amplify CLI with this feature flag set to |
Hi @iartemiev - thanks for your message. Firstly, yes that field/fields thing was a typo above. Secondly, the above is generating for you as "HAS_ONE", whereas most of mine are generating as "BELONGS_TO" (154 instances Vs 12 HAS_ONE instances). A little more expansion on this - I think that if I have a 2 sided connection it is causing the BELONGS_TO rather than HAS_ONE to be created - and not creating the assetPlantId field on the Asset model.
This is the cli.json that I am using.
|
This is also causing us issues in DataStore Sync
|
Hi @iartemiev - can you comment on this - when I do amplify codegen models and I have a "one sided connection" it generates a "HAS_ONE" connectionType - and importantly it includes the targetName as a field on the model.
BUT, if the connection has 2 sides (ie. @key ) then it creates a BELONGS_TO connectionType. It does not include "associatedWith": "id" in the association and it does not include the targetName as a field that is then queryable.
At the moment I have to manually add the targetName field to the schema.js file for BELONGS_TO connections - and in the index.d.ts I need to add the same fields to "export declare class ". Any thoughts/comments appreciated - am concerned about such significant edits I'm having to make to codegen models. |
@sacrampton that is currently the expected behavior for Has One vs. Belongs To, however, we're looking into including the connection field in the generated model, so that it can be queryable. |
@iartemiev - just want to confirm that by editing the schema.js to add the fields (had to make them optional even if they were mandatory) and the "export declare class " in the index.d.ts files that this gets DataStore working with those fields being queryable. Is a significant undertaking the first time - but after that you can use something like Visual Studio Code to manage changes between versions without having to redo everything. |
Thank you, @sacrampton, I understand that that's the workaround you're using. Before we (the Amplify team) make that change in the codegen library, we need to consider the ramifications of doing so and whether there are better alternatives for exposing those fields. I'll keep this issue updated as we make progress on this. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems. |
Are there any work-arounds for this problem? |
This appears to still be an issue. I'd like to query by the "belongsTo" ID but cannot, even though as @sacrampton pointed out, if you manually add this field (relatedId) in schema.js, it works as expected. I'm not sure why this is something DataStore doesn't do automatically when creating your schema. If I'm specifying a field of relatedId in my schema, I'd expect it to be queryable. However, it does seem like there's a solution to this, even though I found it slightly unintuitive: So I appreciate the documentation there. |
I also discovered that if you omit the "fields" argument in a connection, this will sometimes give you access to the relatedID field. It creates the field in the schema.js file, same as @sacrampton was doing manually. However, this doesn't seem to ALWAYS work, and I can't say why. But it may be worth a shot. type Comment @model { |
Hi @justinjaeger - just FYI, your example follows the V2 transformer syntax. If you have an existing production system of any size then you can't move from the V1 schema due to the failures around stack mapping (aws-amplify/amplify-category-api#32). Until we are able deal with these ongoing issues with the V2 transformer we are all stuck on V1. |
Before opening, please confirm:
JavaScript Framework
Not applicable
Amplify APIs
DataStore
Amplify Categories
api
Environment information
Describe the bug
See the code snippet below - but the id of the connected model is not available to query within DataStore.
In our GraphQL application, if I want to query for all assets in the same plant in GraphQL I would query for assetPlantId = the Plant ID I want and I can retrieve connected plant information.
However, in DataStore, whilst I can query for an asset and get related plant information when I query an asset, I can't query on the ID field (ie. assetPlantId) - it shows that it doesn't exist in the model even though it is in the GraphQL schema and I can query in GraphQL with it.
Expected behavior
That DataStore allows me to query the ID of the connected record
Reproduction steps
See code snippet below.
Code Snippet
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response
The text was updated successfully, but these errors were encountered: