Example

[bubnenkoff]

Oh! Very interesting project!
Could you give examples how to use it?

P.S. there is very good lib for work with http https://github.com/ikod/dlang-requests it maybe helpfull.

[ReneZwanenburg]

Hi,

This project is far from finished, and the API isn't stable yet. At any rate the idea is to use the interfaces in combination with Vibe's Rest client generator to provide a direct mapping of the Arango APIs, and to layer something easier to use on top later.

The arango API is defined here:
https://docs.arangodb.com/3.1/HTTP/index.html
So far I've only done the Collection, Document, and Cursor APIs.

A small example of something that already works (untested, I'm not at my pc right now):

import arangoclient;
auto db = arangoClient("http://localhost:port", "myTestDatabase", "userName", "password");

static struct Message
{
  string name, message;
}

db.document.add("messages", "someKey", Message("foo", "bar"));

static struct QueryArgs { string name; }
foreach(message; db.cursor.query!Message("FOR message IN messages FILTER message.name == @name RETURN message.data", QueryArgs("foo")))
{
  writeln(message);
}

The reason for using message.data as query return value is that, as of this moment, Vibe's REST framework does not allow specifying full body parameters. That means all the data you post to the db using document.add(...) is wrapped inside a data member of the actual document in the database.

If vibe-d/vibe.d#1676 gets pulled I'll be able to clean this up.

[bubnenkoff]

Thanks for response!

Is there difference between working with http and some more native drivers? I thought that native drivers should work faster because afaik they use some compact binary protocols.

[ReneZwanenburg]

To my knowledge all ArangoDB drivers use the HTTP interface under the hood. AFAIK it's the only interface to the database. It's true that a binary protocol might be a bit smaller, but since ArangoDB data model is based on free form JSON documents you'll always get the fieldname: value overhead on some form or another.

But compression of the requests and responses should already take care of the bulk of it ;)