Driver/client strategy?

[timw]

Congrats on the launch - it's a really positive development for OrientDB users, and hopefully it gets to production ready soon!

The first question I have while browsing the docs/code, is: what is your strategy/intention for drivers/clients?

I do like the simplicity of having a baseline polyglot query language REST API (Elastic Search has got a long way with that approach), and implementing the PostgreSQL wire protocol seems really pragmatic as well. I'm less convinced about the MongoDB/Redis approaches, but time may prove me wrong on those :)

I am left wondering a few things while pondering how we could port our app to ArcadeDB:

• Do you intend for the native (Java) API to be remote at some point?
• What are your intentions with the PostgreSQL server with respect to exposing documents or other composite results?
• Do you intend to create a driver/client that utilises the HTTP API?

For reference, we utilise a graph model as a transactional database, so our query load is a mix of document fetches and projections over a reasonably small cluster of vertices.

[lvca]

Thanks, @timw. You can already use the RemoteDatabase class that is just a wrapper of HTTP api

[lvca]

Missed the other questions:

• We don't plan to have the same abstraction we had in OrientDB, but you can already use com.arcadedb.remote.RemoteDatabase class, which is a wrapper of HTTP API
• Through the Postgres driver, all the results are flattened to tables. If there can be other ways to expose the resultset I'd evaluate alternatives
• See above: com.arcadedb.remote.RemoteDatabase is already available. We're going to update the docs with it asap

That use case is perfect with ArcadeDB. I'm sure if you import the database and play with Arcade you'll notice the performance improvement from the first query