search

realm / realm-js

Realm is a mobile database: an alternative to SQLite & key-value stores
https://realm.io
Apache License 2.0
5.74k stars 565 forks source link

Better handle object property comparison/equality/identity #19

Open alazier opened 8 years ago

alazier commented 8 years ago

If you get a non primitive property it will not be the same object that was set. From @appden :

it would be ideal for objects (i.e. non-primitive values) to survive a roundtrip. Right now the getters look like they always return a new JS object, which will inevitably cause unexpected weirdness in JS code, especially now that we have native Map and Set collections. As long as each object in Realm has a unique identifier, I think this will be relatively easy to achieve

alazier commented 8 years ago

I'm not sure this will be possible to do, but at a minimum it would be nice if == worked for all object types even if === does not.

appden commented 8 years ago

I'm almost positive there is no way to override == behavior for object comparisons. Do objects inside a Realm have some kind of unique identifier so we could track live objects exposed into a JS context? When I built a JS-ObjC binding, I accomplished this thanks to each object's "unique identifier" being its pointer. :smile:

appden commented 8 years ago

We discussed last week that this would be possible for objects that have a primary key, since we can use the value of the primary key to track live objects in the JS context. I prototyped this in PR #118, and it works, but doesn't yet support changing the primary key on an object.

I believe this is more than just a "nice to have" since we cannot override == and object hashing like we can in the ObjC and Swift bindings (I know ObjC uses -isEqual, not ==, but that fits with how Cocoa works). Those bindings only support equality for objects with primary keys as well, so I think that a valid enough precedent for the JS binding to work similarly rather than blocking this issue on some future object id support in core.

Adding this would not only benefit us from having a functional == for primary-keyed objects, but would also allow for them to be used with Array.prototype.indexOf (and friends) as well as with Maps and Sets.

kneth commented 4 years ago

We are going to add some kind of unique id in the near future, so we should wait until it has been introduced in core/sync.