Change schema definition format about realm-js

[alazier]

We will need a dynamic api similar to the current implementation as this is currently being added to the other bindings. We can explore automatic schema inference but there are some big issues such as support for non-native js types (int, float, data, etc) which may be difficult to specify in an elegant way.

[appden]

I'm personally in favor of continuing to be explicit, but losing the order dependency. I like the React.PropTypes API overall, so I think we could model the schema representation to be similar...

PersonObject.schema = {
  name: 'PersonObject',
  properties: {
    name: Realm.Types.string,
    age: Realm.Types.double,
    children: Realm.Types.arrayOf('PersonObject'),
    // Also allow these for setting more options...
    limbs: {type: Realm.Types.int, default: 4},
    career: {type: Realm.Types.string, optional: true},
  }
};

In addition, I think it's more appropriate to have the schema be set as a static property of the constructor rather than on the prototype. This is how React's propTypes works, and won't cause issues with someone creating a schema property on objects. Furthermore, perhaps it would be safer to be even more explicit by instead naming this property realmSchema (just a thought).

[alazier]

Using a map rather than an array of properties looks good to me. We can't set the schema as a static property on Realm as we need to support access to multiple realms with differing schema.

[appden]

Sorry, I meant a static property of the constructor of an object rather than on its prototype. For example, inside TestObjects.js the PersonObject class would have schema (or realmSchema) set directly on PersonObject rather than PersonObject.prototype.

[alazier]

So it sounds like we can't do this at the moment as we need to support column ordering in order for sync to work. In the future if the constraint is laxed then we can support the proposed format.

[appden]

So my primary issue is with the look and feel of the current API, not necessarily with the columns having intrinsic ordering. This also relates to #112, which is that I want to remove creating objects from arrays of properties.

In JS, the property keys will still have ordering in my proposed new API, meaning iterating over those keys or calling Object.keys will always be in the order as defined. The only issue is that encoding those into JSON makes them lose their ordering (since JSON keys have unspecified ordering), so we'd need to change the RPC serializing and deserializing techniques to retain the ordering over those keys, which is quite easy. 😄

[alazier]

Does JS ensure that keys will retain the ordering in which they are defined?

[appden]

Yes it is guaranteed in the language. I actually have all of this working in my sk-schema-api branch.

[alazier]

I don't think this is guaranteed for Objects: http://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order

[appden]

Yes it is. Older versions of ECMAScript left it unspecified, but all engines have maintained insert order and many libraries and websites have come to depend on it, so ES6 retroactively officially added this to the specification since all engines had this behavior anyways.

[alazier]

From the ES6 spec:
The mechanics and order of enumerating the properties is not specified

[appden]

You're right, I was partially mistaken. The spec doesn't require the engine use insertion order for enumerating properties, but it does require that engine to maintain insertion order since it requires Object.getOwnPropertyNames(object) to return property names in insertion order.

[alazier]

Lets finish this this week. I think we need to make the change to the schema format. We shouldn't rip out array support and I don't think it is necessary to refactor all the tests a this time, although if there aren't any conflicts we can keep the current changes. Moving forward we can write new tests using objects rather than arrays if that is preferable,