Manual referencing not resolving

[mingard]

I created a reference within a document body, something like:

Collection: Parent

{
  "name": "Parent Document",
  "friend": {
    "@key": "RelatedDocument@b0f16ff1-15aa-4187-b501-418678463fe8"
  }
}

The intention is to relate one document to another. It works if I reference an Object but not a custom type. Error is thrown here with an error similar to

"err":{"message":"RelatedDocument is not defined"

There is a RelatedDocument db, and it's populated with a document with that @key

Is there a better way to insert a related document too?

[anywhichway]

@mingard you are using the browserified lib/index.js which makes it really hard to debug. Is there any chance you can use the src/index.js (requires recent NodeJS with harmony flags or recent Chrome)?

[anywhichway]

@mingard you might try making this call right after you start the database: db.index(RelatedDocument).

Although, the root problem seems to be that RelatedDocument is not in scope for nestedtypes.push(new Function("return " + clsname)())'. So, as a debugging hack you might also try editing the source at the line you identified to be like this: nestedtypes.push(new Function("return " + clsname)({RelatedDocument}))or even just put aconsole.log(RelatedDocument)` on the line before.

[mingard]

@anywhichway I'll give that a shot. I'm using reasondb on the server with NodeJS 6.9 - is that an issue?

[anywhichway]

@mingard not if you are using the lib file. Development here is done in v7.x with --harmony-async-await so we can directly debug the code that is written.

BTW, thanks for the paces you are putting reasondb through.

[mingard]

@anywhichway I'll try with the suggested debug method.

Re: Putting reasondb through it's paces, you're very welcome. It is already proving exceptionally performant.

[anywhichway]

@mingard There are three reasons for the performance:

1. Utilization of the many hours of optimization that have been applied to JavaScript property lookup by vendors and using that for index keys.
2. The use of a lazy cross-product for result sets.
3. The JSONBlockStore ... which us faster than we expected. Make sure you do frequent back-ups on this. We have not yet built utility code to do recovery if it somehow gets out of whack.

[mingard]

@anywhichway I tried the hack but it doesn't work for me. I could try and recreate again in a test.

When nestedtypes.push(new Function("return " + clsname)()) is called, there is a presumption that the class already exists.

It does exist if the type is Object or one of the core primitives however if the type is SomeOtherCollection that you've previously pushed data into, it doesn't recognise it.

I tried defining the second schema in the request on the off chance that would work.

class ParentCollection {

}

class ChildCollection {

}

let query  = db.select()
    .from({$p: ParentCollection, $c: ChildCollection})
    .where(where)

This didn't force the recognition of the ChildCollection

[anywhichway]

@mingard Let us dig in a little more. Since we know where the problem is in the code, it is more a question of figuring out why the scope is wrong than having an example that shows the problem.

[anywhichway]

@mingard try calling db.index(ChildCollection) before you call db.select(); If this does not work try adding ChildCollection to the scope of the store you pass to the database, e.g. store.scope["ChildCollection"] = ChildCollection.

[mingard]

@anywhichway I tried both, in that order and then a combination but still no luck. It does however seem to successfully add the scope key. I had to call an index on the ParentCollection first before it had been added as an index. My script looks like this:

db.index(ParentCollection)
db.index(ChildCollection)
ParentCollection.index.store.scope.ChildCollection = ChildCollection

And the scope looks like this:

{ ParentCollection:
   { [Function: ParentCollection]
     index:
      Index {
        saveAsync: true,
        keys: {},
        store: [Object],
        name: 'ParentCollection',
        pending: {} } },
  ChildCollection:
   { [Function: ChildCollection]
     index:
      Index {
        saveAsync: true,
        keys: [Object],
        store: [Object],
        name: 'ChildCollection',
        pending: {} } } }

[anywhichway]

@mingard So are you saying your code still fails but the scope is set?

[mingard]

@anywhichway That's correct. The exact same error occurs. Is there anything I can do to help debug?

[anywhichway]

@mingard At this point I think we are going to need a working example of the problem. We know where the bug manifests but not the source of the issue. https://github.com/anywhichway/reasondb/tree/i18 has been pushed with a subdirectory test/issues/18 where you can drop some code.

[mingard]

@anywhichway Thanks, will do

[anywhichway]

@mingard During a code walk through an error was found in JSONBlockStore where it was not updating the scope map. Does this scope issue occur if you use LocalStore?

[mingard]

@anywhichway I'm not sure - how can I test this? I can tell you that after saving and restarting the app using LocalStore, references are no longer resolved

[anywhichway]

@mingard So have we introduced a new error? Or is it that the original error your reported still exists?

[mingard]

@anywhichway It has been that way since I first tried using LocalStore, which was a long time ago. It was the reason I switched to JSONBlockStore. Nothing new! I meant to raise a ticket - will do this soon.

[anywhichway]

@mingard Aha! Thanks.

[anywhichway]

Closed for inactivity. We believe the original issue has been resolved in the v1.x.x releases.