sql support about seneca-store-test HOT 6 CLOSED

@rjrodger see here for the tests https://github.com/rjrodger/seneca-store-test/blob/master/store-test.js#L457

from seneca-store-test.

no - this is not correct - is not allowed directly :)
a string in this position is always an opaque id

however, we can support { $native:"SELECT..." } as the query parameter - I think this is a valid use case, as it supports generating entity objects from a native query

note that this feature now applies to all stores, but is OPTIONAL - so we now introduce the idea of optional store features....

frameworks are fun

from seneca-store-test.

I'm afraid opaque id feature is not mentioned anywhere, I'll add tests for that.

I'll convert the the sql tests to use the native$ option. This will break backward compatibility on some of the stores.

About being optional to some of the stores, seneca-store-test is already constructed in way that makes easy to import and run only relevant tests (e.g.: basics, but not native sql)

from seneca-store-test.

@rjrodger I was wondering, is the "opaque id" supposed to work with the list$ command too?

from seneca-store-test.

@rjrodger Additional question: how is { native$: ... } supposed to work?

from seneca-store-test.

list$ should be able to take an array of ids as the query... so a degenerate case is a single id - so yes, opaque ids work for list$ too

{ native$:"SELECT * FROM foo" } should execute the query, and then construct -/-/foo entities using the result set.

from seneca-store-test.