I might be a good idea to take a in an object (key value pairs) for querying instead of having people put together a string.

It would work for single parameter queries. If there are multiple it would assume AND -- these seems to be the most common case.

Notes;

• allow empty query or null to be no filters
• auto escape strings and such
• ideally on a string or int column, i should be able to give an array - this would translate to an IN query if it was MySQL. ActiveRecord does this and I think it's super useful.

Run tests in cordova and run from CI

We can delete row indexes directly operating on table_view/link_view rather than creating a wrapping object for each object.

the first complaint was that i couldn't find node
I am using nvm so added source ~/.nvm/nvm.sh in the sample Run Script.
That seemed to get past it

The native Array methods convert those strings to numbers internally. We should do the same. This bit me hard in React Native because ListViewDataSource passes around all row indexes as strings.

Right now we only test on simulator

some of the issues that I'm seeing could be attributed to crashing if the value is undefined.

I'm calling realm.create(data)
let's say the table has a column named title but I leave it off the data object.

I think it's crashing with "should be a string"
I was expecting it to set the value to NULL if left off.

The example app should use as many of the api features as is reasonable.

@appden am I recalling correctly that we decided on this at some point but simply did not create an issue?

For tests, we need to clear/truncate all the tables.
What's the best what to do that?
I'm currently iterating through each and realm.objects(name).delete(results);

Is there one method to start over the whole db?

At the moment there is no testing of our migration functionality

Right now we never stop the rpc server.

From @appden :

I'd like to modify the array and results implementations to properly inherit from the native JS Array so we can leverage all of its methods. To do this, we just need to implement getters (and setters in the case of Array) for indices and the "length" property. JavaScriptCore will handle everything if we just do that (I believe the spec enforces this behavior, but I'm not quite sure of the details). Its native class name should be "Array" as well since many libraries expect this to check if an object is an array.

Something is happening that prevents the injection of the Realm and RealmType globals in to the JS framework when you upgrade react to the current version.

You can see the issue in the example app if you change the package.json to:

  "dependencies": {
    "react-native": "0.10.0"
  }

Our single test currently waits for a few seconds to make sure no exceptions are thrown. We should change the test to make sure the UI actually loads property. I was unable to get the current check to work in the few minutes I spent on it so commented out the relevant check.

is there a way to UPDATE table_name SET prop1=14 WHERE prop2='key' ?

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

I wanted to be sure this was tracked. I really like that the current tests run inside Xcode and now will report the exact failure location in JS (see #29). However, we also will need to run these tests inside all of our supported platforms: iOS/Android devices, inside Chrome (once we get that working), Node, etc.

I propose that we migrate our existing test suite to use Mocha. Since Mocha is very modular with swappable assertion libraries and reporters, we'll be able to easily support all environments including Xcode. We can even write a custom reporter that shows test progress with React Native views. It'll be trivial to write a reporter to leverage our existing test suite code to report failure info in Xcode. The existing Terminal and DOM reporters will work well with our respective Node and Chrome environments as well. 😄

We need to be able to do this both with and without chrome debugging.

For ci, we need to be able to run the tests from the commandline either through XCode or another test harness.

say i know the primary key - is there a way to update just a few of the properties?
right now it all goes through create (with the true flag) and it crashes if all the properties are not set.

React uses AsyncStorage and we can just write an object (json) to disk.

I'm thinking I want to do that in Realm. That is, any given table would have a "document" column and I'd put a bunch of JSON in there. The other columns would only be things I wanted to filter or sort by.

Is that crazy? Here are some of the benefits

• I can actually have a null value :-)
• I can do simple nesting - which is a easier and more reliable than making object graphs in the db
• less migrations
• more or less can cache what comes from the server

The downsides are probably something like the downsides to NoSQL in general

• there are still "migrations" - it's just internal versioning stuff

If it is a not-crazy idea, would I just store a String of the json or is there some more native way to do it?
Is there a string size limit? I see something about 16 MB in the docs for a property.

@appden :

I think JS devs would generally prefer to write out regular objects in similar way as the React.PropTypes API, and I think it would make it easier to read code wherever those objects are created. It also would allow devs to reorder the property definitions for cleanliness without worrying about breaking lots of code. We can discuss this more next week – perhaps there are benefits I'm not realizing.

Maybe some documentation on the sample react project?

I did an npm install then launched the xcode proj
It's still giving me a build error

Thoughts on that?

I have a table with about 30 rows or so. I was trying to simulate the "delete with a query" method I'd like.

RealmStore.prototype.deleteAll = function(query) {
  realm.write(function() {
    this._deleteAll(query);
  }.bind(this));
};

RealmStore.prototype._deleteAll = function(query) {
  // TODO: optimize to one call
  var results = realm.objects(this.name, query);
  var toDelete = [];
  for (var i=0; i < results.length; i++) {
    toDelete.push(results[i]);
  }

  if (toDelete.length > 0) {
    realm.delete(toDelete);
  }
};

This causes the crash below.
Another note: At one point I was deleting them one at a time in the loop. This did not crash but also did not actually delete them all.

table.cpp:1983: [realm-core-0.92.0] Assertion failed: row_ndx < m_size [19, 18]
0   RealmJS                             0x00000001101f5261 _ZN5realm4util18terminate_internalERNSt3__118basic_stringstreamIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE + 40
1   RealmJS                             0x0000000110147ae0 _ZN5realm4util9terminateImmEEvPKcS3_lT_T0_ + 1600
2   RealmJS                             0x000000011022edb4 _ZN5realm5Table9erase_rowEmb + 436
3   RealmJS                             0x00000001101b2949 _ZN5realm5Table6removeEm + 41
4   RealmJS                             0x00000001101ec69b _Z11RealmDeletePK15OpaqueJSContextP13OpaqueJSValueS3_mPKPKS2_PS5_ + 1067
5   RealmJS                             0x00000001101ec394 _Z11RealmDeletePK15OpaqueJSContextP13OpaqueJSValueS3_mPKPKS2_PS5_ + 292
6   JavaScriptCore                      0x000000010e0c6825 _ZN3JSC19APICallbackFunction4callINS_18JSCallbackFunctionEEExPNS_9ExecStateE + 517
7   JavaScriptCore                      0x000000010e18d326 _ZN3JSC5LLInt9setUpCallEPNS_9ExecStateEPNS_11InstructionENS_22CodeSpecializationKindENS_7JSValueEPNS_17LLIntCallLinkInfoE + 454
8   JavaScriptCore                      0x000000010e194387 llint_entry + 22753
9   JavaScriptCore                      0x000000010e194327 llint_entry + 22657
10  JavaScriptCore                      0x000000010e18e881 callToJavaScript + 311
11  JavaScriptCore                      0x000000010e072ea3 _ZN3JSC7JITCode7executeEPNS_2VMEPNS_14ProtoCallFrameE + 35
12  JavaScriptCore                      0x000000010e0558a0 _ZN3JSC11Interpreter11executeCallEPNS_9ExecStateEPNS_8JSObjectENS_8CallTypeERKNS_8CallDataENS_7JSValueERKNS_7ArgListE + 480
13  JavaScriptCore                      0x000000010de91fde _ZN3JSC4callEPNS_9ExecStateENS_7JSValueENS_8CallTypeERKNS_8CallDataES2_RKNS_7ArgListE + 62
14  JavaScriptCore                      0x000000010e0c59fd _ZN3JSC17boundFunctionCallEPNS_9ExecStateE + 605
15  JavaScriptCore                      0x000000010e18ea1f callToNativeFunction + 317
16  JavaScriptCore                      0x000000010e0558ef _ZN3JSC11Interpreter11executeCallEPNS_9ExecStateEPNS_8JSObjectENS_8CallTypeERKNS_8CallDataENS_7JSValueERKNS_7ArgListE + 559
17  JavaScriptCore                      0x000000010de91fde _ZN3JSC4callEPNS_9ExecStateENS_7JSValueENS_8CallTypeERKNS_8CallDataES2_RKNS_7ArgListE + 62
18  JavaScriptCore                      0x000000010e116190 JSObjectCallAsFunction + 688
19  RealmJS                             0x00000001101ec996 _Z10RealmWritePK15OpaqueJSContextP13OpaqueJSValueS3_mPKPKS2_PS5_ + 294
20  JavaScriptCore                      0x000000010e0c6825 _ZN3JSC19APICallbackFunction4callINS_18JSCallbackFunctionEEExPNS_9ExecStateE + 517
21  JavaScriptCore                      0x000000010e18d326 _ZN3JSC5LLInt9setUpCallEPNS_9ExecStateEPNS_11InstructionENS_22CodeSpecializationKindENS_7JSValueEPNS_17LLIntCallLinkInfoE + 454
22  JavaScriptCore                      0x000000010e194387 llint_entry + 22753
23  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
24  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
25  ???                                 0x0000013fd92ece4d 0x0 + 1373738290765
26  ???                                 0x0000013fd9393407 0x0 + 1373738972167
27  JavaScriptCore                      0x000000010e194392 llint_entry + 22764
28  JavaScriptCore                      0x000000010e194392 llint_entry + 22764
29  JavaScriptCore                      0x000000010e194392 llint_entry + 22764
30  JavaScriptCore                      0x000000010e194392 llint_entry + 22764
31  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
32  JavaScriptCore                      0x000000010e19455c llint_entry + 23222
33  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
34  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
35  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
36  JavaScriptCore                      0x000000010e194327 llint_entry + 22657
37  ???                                 0x0000013fd93ace08 0x0 + 1373739077128
38  ???                                 0x0000013fd9349775 0x0 + 1373738669941
39  ???                                 0x0000013fd928ca6f 0x0 + 1373737896559
40  ???                                 0x0000013fd927439d 0x0 + 1373737796509
41  ???                                 0x0000013fd9297cbe 0x0 + 1373737942206
42  ???                                 0x0000013fd93311da 0x0 + 1373738570202
43  ???                                 0x0000013fd921a44a 0x0 + 1373737428042
44  ???                                 0x0000013fd92974ee 0x0 + 1373737940206
45  ???                                 0x0000013fd926f318 0x0 + 1373737775896
46  ???                                 0x0000013fd91f59fa 0x0 + 1373737277946
47  ???                                 0x0000013fd9293813 0x0 + 1373737924627
48  ???                                 0x0000013fd91f5a3a 0x0 + 1373737278010
49  ???                                 0x0000013fd9259a59 0x0 + 1373737687641
50  ???                                 0x0000013fd9296a67 0x0 + 1373737937511
51  JavaScriptCore                      0x000000010e18e881 callToJavaScript + 311
52  JavaScriptCore                      0x000000010e072ea3 _ZN3JSC7JITCode7executeEPNS_2VMEPNS_14ProtoCallFrameE + 35
53  JavaScriptCore                      0x000000010e0558a0 _ZN3JSC11Interpreter11executeCallEPNS_9ExecStateEPNS_8JSObjectENS_8CallTypeERKNS_8CallDataENS_7JSValueERKNS_7ArgListE + 480
54  JavaScriptCore                      0x000000010de91fde _ZN3JSC4callEPNS_9ExecStateENS_7JSValueENS_8CallTypeERKNS_8CallDataES2_RKNS_7ArgListE + 62
55  JavaScriptCore                      0x000000010e0c59fd _ZN3JSC17boundFunctionCallEPNS_9ExecStateE + 605
56  JavaScriptCore                      0x000000010e18ea1f callToNativeFunction + 317
57  JavaScriptCore                      0x000000010e0558ef _ZN3JSC11Interpreter11executeCallEPNS_9ExecStateEPNS_8JSObjectENS_8CallTypeERKNS_8CallDataENS_7JSValueERKNS_7ArgListE + 559
58  JavaScriptCore                      0x000000010de91fde _ZN3JSC4callEPNS_9ExecStateENS_7JSValueENS_8CallTypeERKNS_8CallDataES2_RKNS_7ArgListE + 62
59  JavaScriptCore                      0x000000010e116190 JSObjectCallAsFunction + 688
60  Tasker                              0x000000010c18a00d __62-[RCTContextExecutor executeJSCall:method:arguments:callback:]_block_invoke_2 + 1389
61  Tasker                              0x000000010c1897e0 __62-[RCTContextExecutor executeJSCall:method:arguments:callback:]_block_invoke + 368
62  Tasker                              0x000000010c18b798 -[RCTContextExecutor executeBlockOnJavaScriptQueue:] + 248
63  Tasker                              0x000000010c189565 -[RCTContextExecutor executeJSCall:method:arguments:callback:] + 821
64  Tasker                              0x000000010c193dcb -[RCTBatchedBridge _actuallyInvokeAndProcessModule:method:arguments:] + 1051
65  Tasker                              0x000000010c196bd9 -[RCTBatchedBridge _jsThreadUpdate:] + 2857
66  QuartzCore                          0x000000010ebcc10f _ZN2CA7Display15DisplayLinkItem8dispatchEv + 37
67  QuartzCore                          0x000000010ebcbfd7 _ZN2CA7Display11DisplayLink14dispatch_itemsEyyy + 315
68  CoreFoundation                      0x000000010d36f174 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
69  CoreFoundation                      0x000000010d36ed35 __CFRunLoopDoTimer + 1045
70  CoreFoundation                      0x000000010d330d3d __CFRunLoopRun + 1901
71  CoreFoundation                      0x000000010d330366 CFRunLoopRunSpecific + 470
72  Tasker                              0x000000010c18778b +[RCTContextExecutor runRunLoopThread] + 363
73  Foundation                          0x000000010c64c09d __NSThread__main__ + 1194
74  libsystem_pthread.dylib             0x00000001109ef05a _pthread_body + 131
75  libsystem_pthread.dylib             0x00000001109eefd7 _pthread_body + 0
76  libsystem_pthread.dylib             0x00000001109ec3ed thread_start + 13
IMPORTANT: if you see this error, please send this log to [email protected].

Selecting plugged in iPhone as target (after compiling jS and changing app delegate.

dyld`dyld_fatal_error:
->  0x1200a1088 <+0>: brk    #0x3

dyld: Library not loaded: @rpath/RealmJS.framework/RealmJS
  Referenced from: /private/var/mobile/Containers/Bundle/Application/F34937D1-35DE-489C-87A7-0A2666B63130/ReactExample.app/ReactExample
  Reason: image not found

I've gotten a crash due to this issue.

They instead always report the same location in RealmJSTests.mm.

I don't expect it to work, but the whole app crashes during Obj-C load.

Stack track of crash...

i don't see an api for sorting. current use cases involve int columns.

This is a common pattern with most databases. Right now, methods that do mutations generally shouldn't call realm.write() because you may which to call multiple mutating methods all inside a single transaction. When the codebases get larger, this maybe be difficult to manage without nested transaction support.

One really great thing about React Native is the ability to reload (cmd + R).
I've just noticed that (understandably) this causes some problems when fiddling around with the schema.

The first thing I noticed is that it doesn't take effect until a hard relaunch of the app from XCode.
The second is that it then requires a migration (maybe because I changed a column type - not sure about adding a column yet).

I'm not sure the right solve for these, but thought I'd note things as I encounter them.

Previous attempt was in the al-safari branch

Steps needed to make this happen:

• Build a native module which includes all the cpp files here https://github.com/realm/realm-js/tree/al-android/src - If the JSCore apis are really the same then everything here should pretty much just work
• Implement the platform specific methods for java/android - empty implementations are in this file https://github.com/realm/realm-js/blob/al-android/src/android/platform.cpp
• Get a hold of the JSContextRef created here and call RJSInitializeInContext with this context to initialize our apis. On iOS we do this in our native module whenever the Bridge gets set. All of the contexts seem to be available in this global variable static std::unordered_map<JSContextRef, JSCExecutor*> s_globalContextRefToJSCExecutor;. If we can find a way to access this from our module initializing the context should be straightforward. Alternatively we can change the react-native implementation in a cleaner way in order to expose the JSContext in a cleaner way. Ideally this would be exposed through a jni method on one of the Java objects passed into our native module during initialization. This will require building our own custom version of react-native until we can make a pr against their repo, but this may be the route that we need to follow.
• Get chrome debugging working. This involves added an http server which hooks into the existing rpc code, and hooking into react native to initialize this webserver whenever chrome debugging mode is used.

We need a query engine that works cross platform and does not rely on objc.

Here are the notes on the subject from Realmstravaganza:

• What do we do for javascript?
  • NSPredicate?
  • Builder pattern like java?
  • LINQ like system?
• Java - builder pattern - can fail at runtime with type mismatches
  • people asking for limit/distinct
  • location of sort method this confusing - strict ordering could address this
• JS - consider apis similiar to underscore/lowdash
  • explore lambda functions in js - if we can extract an expression tree from lamda expressions we could have a linq like interface
  • if we can make linq like system work we should.
• Single query language to rule them all doesn't seem practical.

@appden :

I think it's best to follow JS conventions and use the Realm constructor as a namespace for the other ones (i.e. Realm.Type, Realm.Object, and a future Realm.Array). JavaScript devs will appreciate this and it'll make it easier to modularize with ES6 modules as well.

@appden feel free to suggest alternatives here.

We should have our own DataSource implementation that works with Realm.Results and Realm.List in a way that data is not copied unnecessarily.

If you reload the app while in chrome debugging, you can end up in a situation where you have an old js context sending requests to a server associated with the reloaded context.

The solution for this issue is to have a sessionID associated with each rpcServer, and to support simultaneous requests to multiple rpcServers both for the current and old remote jscontexts. We can support these on a single port so we only need one webserver instance.

From @appden :

I think it would be pretty easy to setup a REPL build target using some private JSC APIs. They have a pretty robust REPL implementation that I think we could hook into. This would helpful as a playground for testing things out during development, but more importantly, for users of the JS APIs to learn and try new things quickly.

Need an object cache for all realm objects with persistent ids

Right now we check for realm->is_in_transaction() inside object_accessor code for settings properties and creating new objects, but in the JSC layer for deleting objects and mutating arrays. All of this checks should be inside the object_store layer, which may mean adding new C++ methods for deletion and mutations. This will be good anyways in order to have less code duplication inside the Node API.

Also, from @alazier:

We will want to define a new exception type for mutations outside of write transactions, as other platforms will need to catch this and possibly handle this specific cases anywhere we throw from the shared object store code.

In JS, getters for nonexistent items should always return undefined and not throw. However, setters can still throw.

This is currently not exposed.

I wasn't getting an exception for this. It wasn't obvious to me where the check for transaction is missing in the code either.