Should we migrate from Xarango to Durango about durango

[elbow-jason]

I have not maintained this lib. I know it has a few shortcomings though.

PRs are welcome.

[elbow-jason]

Are they recent breaking changes to Arango's inputs or outputs?

Have you tried doing anything that you thought should have worked but did not?

I noticed that I don't have code in place to handle transactions. It looks like transactions are simple API calls that evaluate JS though. If you need them we can add them.

Additionally, I would like to change the outputs from the Repo functions to more closely match Arango's API responses. I remember thinking that some of the metadata of a response might be necessary for future users of the lib.

[chintan-mishra]

I think you have built Durango based on 3.3.x ArangoDB HTTP API. So, there are no breaking changes. In the case of Xarango, it wasn't updated to work after ArangoDB 3.2.x which was causing unexpected issues.

I might require Transactions in near future (3-5 months).

In Async operations, metadata helps us understand if the task has been completed or not.

I believe the community has very few ArangoDB users and everyone is spinning up their own lib. I would like to collaborate on either Durango or Xarango.

[jnylen]

@chintan-mishra,
I think Durango has a better future than Xarango.

The way Durango has done most things are way better than how Xarango does it, such as the query builder. Some things Xarango does a bit better such as transactions and edges. But it shouldn't be hard to merge both into Durango in a way that makes it work better.

@elbow-jason,
We need some more examples/docs for stuff like changesets etc.
And maybe a way to tag document() and queries to run towards a struct (Durango Model).

[chintan-mishra]

@jnylen Can you please elaborate the query building part? Also, what Durango does better.

We are using Xarango in our prod Phoenix applications. We will have to support Xarango's fork while Durango matures.

About changesets: Trying to make NoSQL DB driver close to Ecto takes away some niceties we get with NoSQLs.

Edit: I liked Xarango's clean separation of concerns. A library user just needs to know about Xarango.Domain.*. A library user doesn't need to worry about what is under the hood.

[jnylen]

@chintan-mishra,
The query building in Durango is basically an array of:

Durango.query(
                for: price in :pricings,
                filter: price.product_id == ^product_id,
                for: s in :stores,
                filter: price.store_id == s._id,
                let: shippingcountries = subquery([
                    for: ship in :shippings,
                    filter: ship.store_id == s._id,
                    return: ship.country
                ]),
                for: ship in :shippings,
                filter: ship.store_id == s._id,
                filter: ship.country == ^country,
                return: merge(price, %{store: merge(s, %{shipping_countries: shippingcountries}), shipping_fee: ship, product: document(price.product_id) })
            )
            |> Server.Repo.execute

With joins etc.

Xarango doesn't have joins at all.

Regarding changeset. I do agree on that, and the whole fields parts feels a bit iffy but I understand why as atoms arent garbage collected.

The only part I liked about Xarango is the graph part i.e.

relationship(Server.Graph.Nodes.Movie, :genre, Server.Graph.Nodes.Genre)

[chintan-mishra]

The only part I liked about Xarango is the graph part i.e.

relationship(Server.Graph.Nodes.Movie, :genre, Server.Graph.Nodes.Genre)

This is true. Relationships in graph come so naturally in Xarango.

[chintan-mishra]

@jnylen @elbow-jason which mode of communication we can use to move the development process in a faster way?

There is a gitter.im channel but it is mostly inactive
@pinx you can add value to this conversation

[jnylen]

@chintan-mishra sorry for the slow answer, no internet for the past few days.
Well I can do anything. I'm more active on IRC though.