Support for NoSQL connector ?

[nvdnkpr]

Are their any plans to create respective NoSQL connector, which forces to implement functions like applyPagination etc?

It's obvious that a connector which transforms a certain structure into a structured language (and vice versa) is somehow restricting the concept of a "No"SQL database ;).

The intention behind my question is that I'm currently re-factoring the loopback-connector-arangodb. ArangoDB (although being a NoSQL database) comes with a structured language called AQL and supports transactions.

So I'm considering to extend the SQLConnector instead the normal connector.

Are there any known caveats or restrictions ? I know that I could just start, but before that I wanted to ask if there is already a plan for NoSQL connectors and/or any experience/thoughts about transforming the SQLConnector for NoSQL Databases

[bajtos]

@raymondfeng could you PTAL? I think you are the most competent person to answer this question.

[nvdnkpr]

Just for clearity: I already built a connector based on the normal connector, where I implemented the methods used for the CRUD methods. The connector also has a query method, and since ArangoDB supports transactions there is also a transaction method. When comparing the SQLConnector methods with my own connector, I see a lot of helper and inner anonymous methods in my connector that have the same function as in the SQL Connector.

My question therefore target if the SQL connector with the SQL and the beginning is a little bit misleading, because in my case if a few methods from the SQL connector would be abstracted to the Connector Class then I would just have to "fill" the methods that the Connector left unimplemented.

If you want to see it for your self, check https://github.com/nvdnkpr/loopback-connector-arangodb/blob/feature-%231-InitialVersion/src/arango.coffee

There you will find

• the query method
• the transaction method
• a method that builds the "WHERE" part (there is no WHERE in ArangoDB, it's FILTER, but I called it WHERE because the model interface provides the WHERE method)

So back to the point and the core question: Some of the methods from the SQL Connector should get abstracted up to the Connector class, but again, does that makes sense ?

[nvdnkpr]

Or this is the second part of the question: Since ArangoDB provides itself a query language, is there more sense in having a QLConnector and then you build a MySQL, PostgreSQL, AQL or whateverQL by inherting from it ? Perhaps the current interface of the SQL Connector is enough and it should just be renamed to QLConnector :smile:

[mrbatista]

@raymondfeng we are waiting for your clarification. This is the same reason why I asked for clarification in google group.

i thank you in advance for your time and consideration.

[raymondfeng]

Maybe we can further refactor the base classes into Connector --> DBConnector --> SQLConnector?

[nvdnkpr]

to be able to answer this I think you should clarify why their is a SQLConnector in the first place ? Is it e.g. in order to have finer control over the connectors, so (just as an example) the auto migration can then automatically call methods to create and drop tables instead of being implemented by the author of the connector? Also there is a trend towards different types of databases (graph-, key/value-, document- databases)every type having it's own special methods and functions.

I think if you want to create an DBConnector class their should be the possibility to mix in certain features in a way like Java defines interfaces so e.g. MySQL = DBConnector + (S)QL mixin PostgreSQL = DBConnector + (S)QL mixin + (if with postGIS) Geo mixin Redis = DBConnector + Key/Value mixin and so on...

So in my case with ArangoDB I would have the DBConnector + graph mixin + document mixin which then would expect certain methods to be implemented which I then can map to methods on the client .

[raymondfeng]

I think you are on the right track. One idea I have in mind is to decouple the model/connector features into a set of mixins (or interfaces). For example, MySQL connector implements:

• KV store
• Pub/sub
• Full CRUD
• Discovery
• Migration
• Transaction

The base classes such as Connector or SQLConnector provides partial implementation of common methods.

[nvdnkpr]

I guess that will go into 2.3 ? or is it compatible with 2.2 ?

[mrbatista]

Any ETA of this features?

[nvdnkpr]

Hello Raymond, what is the time plan for the decoupled connector method. I mean we could start writing a NoSQLConnector for an document and graph databases and then decouple into the interfaces/mixins when you are ready.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

[nvdnkpr]

ping