pyorient Discussion regarding this package and "object graph mappers"

First up I will start by saying that the current pyorient.OGM should probably be moved to it's own package. It makes sense for pyorient to be responsible only for the task of connecting to OrientDB, and the creation of simple objects (the driver, per se). A good reason for doing so is because of the SQL injection vulnerability on the current home page. This was entirely the problem of pyorient.OGM, which is not even related to the 'core' purpose of pyorient. pyorient.OGM wasn't even part of pyorient when I first started using it (as far as I recall). I don't think any other database drivers out there come with ORM's?

Additionally, the inclusion of an OGM probably diminishes the enthusiasm for other, potentially better OGM's to be created. And that's where I chime in with a project that I have started, that is fundamentally different to the pyorient.OGM, and handles the n+1 problem. To be honest, pyorient.OGM seems far too simplistic in its implemention to properly leverage the potential of a graph database.

The intent of this post isn't to bash pyorient.OGM (although it probably sounds that way), but it is to emphasize the idea of "separation of concerns" for pyorient, and to get you knowledgable folk to take a squiz at my module(and maybe even drum up some interest to get it finished). See https://github.com/neRok-/oriental

Jun 14 '16 13:06 neRok00

With just a few (significant) caveats, I agree with you.

The main issue here isn't separating concerns (the OGM is dependent on pyorient, but not at all the other way around). The main issue is making a python OGM for OrientDB accessible to users.

When there is more than one viable alternative, it makes perfect sense for each to have their own project. Then for this project to link to them as pluggable options.

That doesn't look like the case right now.

If the presence of an existing OGM is enough to detract someone from making a better one (it didn't seem to detract you from the effort) - or ironing out the limitations in an existing one - then I sincerely doubt they have the persistence to make something that's viable anyway. It's really not that hard.

I'm curious about your thoughts on some points though:

"oriental does not expect you to write ORM style queries everywhere you want to do a query, rather it expects you to write them once and attach them to your model."

The motivation here is good, but the 'n+1 problem' can be solved in a better way that keeps separate the concerns between the model and the view/controller/whatever's doing the querying.

"First, instead of hiding the creation of queries away from the programmer, oriental expects you to embrace OrientDB’s SQL syntax and write your own queries. I have found that the complex queries possible with OrientDB’s graphs cannot be utilised to their full potential by a system as simple as the one used by pyorient.OGM."

Yep, I'm rubbing up against some of those limitations in applying the OGM to my own pet project. And solving them as I go (e.g., the recent https://github.com/mogui/pyorient/commit/1dab691bdb0088eb362093775c65c21f0c5fe0c1). I'm sure I'll get to the 'n+1 problem' when optimising that pet project is no longer premature, if someone else doesn't beat me to it (hopefully they do!). It's quite possible to address these limitations while preserving the automatic mapping between model class types and their involvement in queries. Which, seems to me, part of the point of an OGM.

Jun 15 '16 00:06 TropicalPenguin

Hi @neRok-, here original author of the driver, Yes you do have a point on the separation of concerns, but also with @TropicalPenguin that being this the first place to look for a python driver give an OGM accessible to users is a great thing. Said that i propose two things:

if @TropicalPenguin (being the main maintainer) wants to move the OGM to its own package, he has only to ask for it :)
We could add a section on the main Readme listing all the project that depends on pyorient, like yours, with a brief description.

Cheers

Jun 23 '16 13:06 mogui

All good points. @mogui, I presume you have done some projects utilising orientdb/pyorient. Based upon this experience, do you have any comments regarding the functionality of oriental?

Jun 27 '16 05:06 neRok00