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

[O-Massol]

Hello,

I'm updating this discussion as I consider my question relevant to this topic.
I'm ok to recreate it as a new discussion or issue if needed.

I'm accessing an ArcadeDB cluster. The cluster is accessible through a proxy/lb.
When I do http calls by curl, or postman, all seems to be good. The cluster itself manages the forward to the leader to do the write request.
As per :

When i'm accessing through RemoteDatabase, I configure it with the host/port of the proxy (initial_url).

The initial call to /server is done to this initial_url.
But (unless i'm mistaken) the RemoteHttpComponent.requestClusterConfiguration() acquires the ha part of the /server response and populates the replicaServerList with server addresses.
However, these server addresses are not accessible to the java application, only the proxy/lb is.

So i'm not sure about what is intended for the RemoteDatabase.
If the access through proxy is not meant to be, i'll be glad to know it.
Otherwise, is it ok to create an issue for a feature allowing to ignore the replicaServerList ? It would allow the use of the java http wrapper RemoteDatabase through a proxy.

And of course i'm open for clarifications and further discussions.

[lvca]

Good point @O-Massol ! I never thought of this use case, but it makes sense. Creating an issue from your comment. Feel free to update it.

[lvca]

I'm still behind on writing a test case for this, but the branch issue-2101 already supports this with the new connection strategy "FIXED": #2102. Is there any chance @O-Massol you can test this branch?

[O-Massol]

It sounds relevant to my use case.
I cannot promise to test it today but I will check that soon !