I’m looking into using Dgraph and pydgraph for a project of mine, and I was wondering if you had time for a conversation about development direction for the python client. I might be able to find significant time for contributions, if our goals are in line. I was specifically thinking about adding something more ORM-ish to the current python capabilities, and possibly implementing a version of sessions that would integrate well with caching systems, and I would be interesting in knowing if dgraph would be interested in those kinds of contributions, and working out the details if so.
Hi @Lyla-Fischer. Happy to hear that you’re looking into using Dgraph! It’s possible that pydiggy fits your needs today. If @ahopkins is around he can elaborate more about pydiggy and if it fits what you’re looking for.
We have no plans to update the official clients with ORM-ish functionality. All of the official Dgraph language clients are implemented as thin clients using only the Dgraph APIs exposed over gRPC (or, in the case of dgraph-js-http, HTTP). This is a deliberate design decision. Here are some of reasons why:
It makes each client easier to implement and update alongside Dgraph.
It enables any client to use Dgraph as long as it can interact via gRPC/HTTP and JSON, which pretty much anything these days. This decouples the official client implementations from requiring any programming language-specific features.
It keeps the developer experience consistent no matter which language client is used.
That said, we’ve seen folks from the community create other client libraries for Dgraph. The aforementioned pydiggy for Python and dgman for Go have ORM-like functionality with Dgraph.
Regarding session management, it sounds like that’d be better served as part of a different component of the application instead of as part of a Dgraph client library. This could be done by a load balancer, for example.
If you come across any other client libraries or create a new one, do let us know and we can link to it from our docs and share it with the community at http://discuss.dgraph.io.
I agree with @danielmai. The client itself should be just that… a client that provides the “low level” connections to the database. To put in similar Python packaging terms, psycopg2 provides access to Postgres, and ORMs are built on top of that.
As far as pydiggy goes, I am still working on a “complete” version. I expect that to be sometime this Summer as I have a few other things I need to polish first. And then I will switch gears back to this and release it along with a project I am working on that will implement it. The library is workable and usable, so I would encourage to check it out and would be happy to hear your feedback.
I am hesitant to call it an ORM, and prefer to call it an object mapper. Why? Because it does not generate the graphql+ queries for you. You still need to write the queries, which it then takes the response back and converts to objects. And then it will handle commuting changes back with migrations. The GraphQL+ language I simply find too powerful that to try and generate it with objects seems like it would not do the language justice. Perhaps this will change in the future. But for now I have no plan to support this.
If with all that said pydiggy sounds like something you are interested in and is headed in a direction you like, I would be more than happy to have some help in bringing it “over the goal line”.
Sounds great, @ahopkins! And thanks for the redirect, @danielmai! I’ll check it out and see if I can use pydiggy as-is, and I would be happy to help push it over the line, as I multi-task with other things. I’ll need some time to get familiar with it, both as a client and as a possible contributor, but I think that your goals make a lot of sense, and I would love to help out! I’ll open an issue in that repo so that you can have a reminder that you have a possible collaborator waiting in the wings.
