Custom/composite identifiers in client SDKs

[bajtos]

By default, LoopBack assumes that each model has id property that uniquely identifies every model instance.

However, LDL allows to customise this:

1. Use different property as the identifier.

   loopback.createModel('Customer', {
     email: { id: true, type: String }
   });

2. Use a composite id - there is a combination of multiple properties that uniquely identifies every model instance.

   // I am not sure if this is the right syntax,
   // correct me if I am wrong
   loopback.createModel('City', {
   state: { id: true, type: String },
   name: { id: true, type: String }
   });

Even when the identifier is not id, the REST API expects a single id parameter in the URL (e.g. GET /customers/:id), even though the JSON documents in requests/responses contain the custom/composite identifier.

This solution brings extra complexity to LB clients.

To begin with, client models need to decide whether they are representing an existing instance or a new object, so that save can call update or create. The current implementations (Android, iOS) are assuming there is always and id property. When this property is set, then the model is an existing instance.

Arbitrary identifiers makes it difficult for front-end developers to use the REST API. For every model, they have to remember what is the identifier and understand when to send it as customId and when as id.

For ids that are not auto-generated (as is the case of the code samples above), we can't decide between update and create just by checking whether the id property was set.

We need a better solution. Thoughts?

/to: @ritch @Schoonology @raymondfeng

[bajtos]

We had a Hangout call to resolve our dispute in an PR for iOS SDK (link), this is the conclusion I remember:

LoopBack should bridge the single id property used by front-end and whatever id properties used by backend datastore. This way the front-end developers don't have to worry about identifiers.

Such approach has a problem too. What happens when the synthesized "id" property (e.g. in the URL) is in conflict with the original properties (e.g. "customId" in the JSON body)?

[seanbrookes]

"LoopBack should bridge the single id property"

Does that mean the LB API will always return an id property on the object instance?

[bajtos]

"LoopBack should bridge the single id property"
Does that mean the LB API will always return an id property on the object instance?

Yes, that's the idea.

Using the two examples in the issue description, it could be

// Customer
{ id: 'customer@company.com', email: 'customer@company.com' }
// City
{ id: '{"state":"TX","name":"Austin"}', state: 'TX', name: 'Austin' }

[fabien]

I've ran into the issue where a manually set id property falsely trumps isNewRecord. This is at the basis of what @bajtos describes, not being able to tell whether to perform a create or update kind of save. Please track if a record was fetched (update) or newly instantiated (create).

[bajtos]

Please track if a record was fetched (update) or newly instantiated (create).

Please open a new github issue for this.