Disambiguate the meaning of _id

[louischan-oursky]

When _id is included as a property of the attrs of Record constructor, it is expected to be a typed id, i.e. my_table_name/some-id

After the record instance is constructed, _id is typeless id, i.e. some-id.

It is very confusing. It would be better to support id as one of the property of attrs which is interpreted as typed id. The new constructor must issue deprecation warning for users who still use _id for the constructor. Then _id will always mean typeless id.

const Note = skygear.Record.extend('note');
const noteRecord = new Note({
  _id: 'note/1',
});
console.log(noteRecord._id); // this logs "1"

[cheungpat]

@louischan-oursky

We have this terminology: Record ID (note/42) consists of Record Type (note) and Record Name (42).

The _id field contains record type information because this is how the data is transmitted from the server to the SDK. The data is passed to the constructor you mentioned so to construct a Record. Because of this, in the forseeable future, _id passed to this constructor will have type information because not doing so will break HTTP API compatibility.

In the realm of the JS SDK, I think the recommended approach is to get Record ID information from id property (without _), which returns record type + record name. You are not supposed to use or know about _id. For this reason there is no point in “disambiguating the meaning of _id”.

You are having problem because you are unable to pass a Record into the constructor to create a new object (i.e. the copy constructor you referenced in #73). To solve this problem is easy: if _id does not contain record type information, the constructor should assume that the record type is the same as the record type when calling extend(...).

[cheungpat]

This should be handled in #73