You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.
#67 Provides a query API, and the ability to serialize queries to RQL, but doesn't provide a plain object API for querying, or a way to restore a query from its serialized representation.
Pulling from the original query issue, this part has still not been implemented:
Domain Specific Languages - There should be two distinct domain specific languages available to leverage the Query API:
Declarative - This API should use simple JavaScript objects (POJOs) to provide a declarative way of describing a query. This allows the query to be easily serialisable to and from JSON. It also allows an easy mechanism for other actors to procedurally generate a query and have it executed by the Query API.
Functional - This should have full functional parity with the declarative syntax but be offered up in chain-able functions, so that a developer can build the query incrementally taking advantage of intellisense and robust type validation via TypeScript. There should also be a mechanism to serialise complete functional queries into the declarative syntax.
Dstore's approach to this was to allow RQL to be used to specify filters, and was provided by a separate mixin. I think we could follow a similar pattern here, providing one or more mixins that extend the query API to support different object formats.
The text was updated successfully, but these errors were encountered:
#67 Provides a query API, and the ability to serialize queries to RQL, but doesn't provide a plain object API for querying, or a way to restore a query from its serialized representation.
Pulling from the original query issue, this part has still not been implemented:
Dstore's approach to this was to allow RQL to be used to specify filters, and was provided by a separate mixin. I think we could follow a similar pattern here, providing one or more mixins that extend the query API to support different object formats.
The text was updated successfully, but these errors were encountered: