arangodb-php
arangodb-php copied to clipboard
arangodb
doctrine style documents
hi,
i would like to ask if you plan to support document classes just like doctrine does for example in its odm. with annotations and all that. because what i can see is that for every object i want to add to db i need to create an instance of a generic base document class, set all properties and save it. so i'm not working with domain objects, but with low level approach.
if your odm was in the style of doctrine's odm, then it would be super cool!
I haven't made up my mind about that yet. I am happy to think more about that, but it would help if you could either send or point to some examples of how the code would then look like from the client/user perspective. thx!
here is a real example from one of my projects, https://gist.github.com/c8b774a672b24d876811, the class is pretty complex, all the others are much simpler, but i guess all of the doctrine features are used in there. it is implmented with the mongo odm. the same approach works for relational databases, couch db and there is also a doctrine 2 ogm for neo4j https://github.com/bazo/Neo4j-PHP-OGM, it is a lot simpler than the official doctrine implementations
On the one hand, building a full Doctrine ODM for ArangoDB seems pretty complex. Furthermore, not all projects out there use Doctrine so there should be some alternative for these. On the other hand, document classes are probably more appealing and to most users so it would make sense to support them. Still, I am concerned that re-inventing Doctrine's mechanisms (e.g. annotations, class generators) for an ArangoDB client is error-prone and not worth it, given that Doctrine already provides them.
At the moment, I see two sensible ways forward:
- building a Doctrine ODM for ArangoDB on top of the existing driver would be my preferred solution. Unfortunately, this would be too much work for me at the moment. If you would like to contribute, or know of anyone else who is willing to do so, this would be great!
- slightly extending the document class in the existing PHP driver so they support fluent property getters/setters, fluent queries etc. This would make it easier to use, however, it still wouldn't come close to Doctrine.
Do you see any other ways of going on or do you have any suggestions on how to proceed?
unfortunately i cant contribute to building an odm, im just a mere user, im not good at building libraries.
Just my 2 cents. I believe the API should give the interface to the DB and anyone who wants to build a simple or full flegded ODM, ORM, ... whatever, can do that on top of the API or build a beast of a full fledged API+ODM. IMHO, the API should remain a lightweight complete interface to the DB.
Jan, do you have any further thoughts on this issue? How do we handle this?
my preference would be to having a doctrine odm for arango on top of the existing low-level driver. however, writing one will take some time and is currently out of scope at least for me. therefore i'd leave the issue open until there's more spare time to start with the implenentation. i would also be happy if someone contributed a doctrine driver, but i guess it's too much work and shouldn't be expected. what do you think?
Am 09.10.2012 um 18:08 schrieb Frank Mayer [email protected]:
Jan, do you have any further thoughts on this issue? How do we handle this?
— Reply to this email directly or view it on GitHub.
Yes, that's my opinion, too. (Posted 2 posts before yours).
Thinking of it, I tend to believe that those types of development are mostly driven by the community, and as soon as people who know how to do such an implementation, need it, they'll launch a project and write it.
Personally I believe that the ArangoDB-PHP driver provides all access to the server and all the means to extend it for more specific environments like doctrine. I mean, if you look at other DB's, the companies or groups behind them provide some form of access to the DB and also leave anything else to the community.
Clearly it would be a nice thing to have a bundle for doctrine and whatever is out there, but then you wouldn't be doing your magic, writing an amazing DB Server. You would be writing, testing, maintaining all those drivers, ODMs etc.
So, I guess what I am saying is, maybe it's better to close this one for now. If at some point there would be enough manpower and time to do this, we could reopen it?
i would even leave the issue open so others can see what's going on (and what's not). they can then see instantly doctrine support idls missing but desired.
Am 09.10.2012 um 20:57 schrieb Frank Mayer [email protected]:
Yes, that's my opinion, too. (Posted 2 posts before yours).
Thinking of it, I tend to believe that those types of development are mostly driven by the community, and as soon as people who know how to do such an implementation, need it, they'll launch a project and write it.
Personally I believe that the ArangoDB-PHP driver provides all access to the server and all the means to extend it for more specific environments like doctrine. I mean, if you look at other DB's, the companies or groups behind them provide some form of access to the DB and also leave anything else to the community.
Clearly it would be a nice thing to have a bundle for doctrine and whatever is out there, but then you wouldn't be doing your magic, writing an amazing DB Server. You would be writing, testing, maintaining all those drivers, ODMs etc.
So, I guess what I am saying is, maybe it's better to close this one for now. If at some point there would be enough manpower and time to do this, we could reopen it?
— Reply to this email directly or view it on GitHub.
OK let's leave it as it is then :)
Actually in terms of the repo object "ArangoDB-PHP" it wouldn't be an issue anymore and should probably be closed, but in terms of what is missed by the community it is still an issue. We should find a correct label to tag this however. Maybe "Framework Bundles" ?
Can you at last implement some way to extend very basic Document class? It won't be that hard and complicated, but allows to keep some logic in one place. Eg. somehing like:
$ch = new CollectionHandler($connection);
$doc = $ch->byExample('collection', ['key' => 'value'], ['documentClass' => 'MyDocument']);
Just for reference: Support for custom document classes was merged into devel through @diabl0 's PR #208 and will be released with version 3.2 of the driver.