Use customised key as primary key for datastore models
It looks like Amplify codegen will generate an ID any way even if we already set customised key for model, here's the a sample amplify schema:
type Book
@key(fields:["bookId", "customerId"])
{
bookId : ID!
customerId : ID!
}
in the generated code class, we can still see a ID field:
primary final @ModelField(targetType = "ID", isRequired = true) String id
And when datastore is storing model data it hard code to check the model's id (since Model is an interface which has a getID method):
https://github.com/aws-amplify/amplify-android/blob/7de77fe56dc79ab1c75a154821e3f1b04bb308d2/aws-datastore/src/main/java/com/amplifyframework/datastore/storage/sqlite/SQLiteStorageAdapter.java#L280
And after taking a look at the database table datastore creates, we found the ID is the primary key.

(sorry have to cover other fields)
Do you think its reasonable to let the primary key datastore's table the same with what we setup in the schema? I also found this is the same across amplify iOS/Android/JS
I saw https://github.com/aws-amplify/amplify-android/issues/846#issuecomment-695140859 , not sure if it already in the roadmap?
Thanks!
I chatted offline with @richardissuperman to understand his use case a little more. His Android application integrates with a preexisting data model, where the primary keys are not in UUID format (e.g. bar codes, serial numbers, etc.). Adding another field for a bar code is not sufficient, because DataStore won't ensure uniqueness. That is, a DataStore.save should determine whether to do a create or update mutation based on whether a record with that bar code already exists or not.
This use case could be solved by removing the UUIDv4 requirement on the id field.
This use case could be solved by removing the UUIDv4 requirement on the id field.
@richardmcclellan what about the use case of Amazon DynamoDB table having partition key and sort key? DynamoDB is not a key value store...
This use case could be solved by removing the UUIDv4 requirement on the id field.
@richardmcclellan what about the use case of Amazon DynamoDB table having partition key and sort key? DynamoDB is not a key value store...
AppSync currently supports custom primary key and sort key(s). See this documentation on the @key annotation to learn how to configure your types.
That said, the Amplify API and DataStore libraries currently assume the primary key is always id. To add custom primary key support in the library, we plan to introspect the schema to determine what the custom defined primary key is, and then use it as the primary key on the SQLite tables, as well as for querying relationships between models.
As for the sort key(s), the libraries will need to include the partition key as well as all sort keys for update/delete mutations, as well as when querying for a single item.
@richardmcclellan when is the plan to allow custom primary key names on DataStore? Currently, I have an application with that use case (where I use @key(fields: ["sub"]) to define my primary key), the whole GraphQL API works just fine, however, Admin UI breaks as DataStore always assume id as the primary key.
@richardmcclellan could you please help me to understand this below phrase from @key annotatio documentation: “Once you are certain that you do not need the old index, remove its @key and deploy the API again.”
my impression is that if we want rename id to another bane as primary key we can first use @key ( fields:[“newname”]) and push to cloud then remove @key and again push. Then when i try it again id becomes prinary key.
Definitely a plus-one for a solution for this issue, integrating with backends that we cannot modify the hash key for.
Any news on that issue? How do you create an app where the primaryKey is the organizationId and the range key is the id of the item stored?
I would appreciate such a solution
Support for custom primary keys has been added to Amplify Android. Please update to the latest version of Amplify Android. Documentation on using custom primary keys with DataStore is available here.
⚠️COMMENT VISIBILITY WARNING⚠️
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.