Thanks to the huge effort of David Funaro and the push from Marco Pivetta we
have just released the
beta-5 version of this library, which lets
you work with the infamous GraphDB in PHP: there is a plethora of
changes and some news about the future of the library, so I’ll try
to recap a bit what we’ve done so far in almost one year of
The entire library (query builder, HTTP binding and ODM) is now composerified (have a look at the dependencies): this was an important step since we wanted to completely get rid of git submodules and embrace this new and – sorry PEAR – finally decent packaging system for PHP.
Symfony2: gimme MOAR
We hate the NIH approach, so whenever there is a library which is tested, decoupled and does what we need, we tend to use it instead of rewriting from scratch some new userland code.
This has been the case for our filesystem classes, that – as they were first very simple but tended to grow – have now been replaced with the Symfony2 finder.
Compatibility with the stable OrientDB 1.2.0
OrientDB is stable since months,
we couldn’t release a version of our library without
upgrading the compatibility to OrientDB (we were still at version
we are now compatible with OrientDB
The move has been quite easy thanks to the test suite that we have
built so far, but we are still probably missing a few features
1.2: as soon as we will go on with the
library we will map what the OrientDB team has added to the DB –
for example, functions.
Fetchplans integrated in the Manager
Fetchplans specify the way OrientDB should lazy-load records:
we have now added support to them,
meaning that if you dont want to lazy-load linked records (
the ODM is able to read the entire result from OrientDB and
build linked records as PHP objects (or array of objects).
In the example,
you see that
- is an array (which eventually contains objects)
- is not a
Proxy\Collection, which would mean it’s a collection of lazy-loaded records
by just using the correct fetchplan:
1 2 3 4 5
We implemented the repository pattern – as Doctrine 2 does: you are now able to access virtual collections and retrieve records through them:
1 2 3 4 5 6 7 8
Since one of our aims is to be as compatible
as possible with Doctrine’s ODMs, we integrated
the Persistence interfaces from Doctrine 2:
most of the methods are not implemented yet (
throw new Exception()),
as actual persistence should come in
the good news is that when retrieving objects from the DB
you can still use the same APIs that the Doctrine ODMs
This release was mainly delayed because of
integration tests1: we promised a fully-tested
hydration mechanisms (converting DB records in
beta-5 and this has been, slowly,
The way we generate proxies is one of the most interesting parts of the library: with this release we changed the way we do it in order to provide a more flexible and straightforward mechanism for doing lazy-loading.
Usually when you retrieve a record in OrientDB you won’t have related records:
1 2 3 4 5 6 7 8 9 10 11 12 13
as you see, by default OrientDB doesn’t
retrieve the related record (
provides a pointer to that record (the
Proxy classes, basically, just call parent methods, and if the parent method has something to return:
- if the returnable is a string, an array, etc or a POPO, they return it
- if the returnable is an
AbstractProxyobject, it means that there is a record/collection of records that have to be loaded from OrientDB with an extra-query
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
As you see, calling the
of a proxied object will make the manager do
an extra-query to retrieve the lazy-loaded record.
Support of sessions in the HTTP client
Daniele Alessandri took his time to add native support for cookies in the HTTP client which is used in the native HTTP binding: thanks to this we can decide whether to re-use an existing session while querying the DB.
I’ve been pretty busy over the last months, but
the efforts of the already-mentioned Daniele and
David have been huge
beta-5: I virtually clap my hands
for them, as they are the main reason behind all
of this progress.
Tests and CI
As always, green tests: the build is handled by Travis-CI. Also that one is green.
Doctrine and beta-6
David is already working on refactoring the namespaces to ask the Doctrine team to integrate the library into their organization: as agreed months ago, there shouldn’t be a big problem in doing so.
As this will be the first ODM for a GraphDB, everyone is pretty excited about it:
- we will get more support and contributions for the library itself
- it’s the first GraphDB that goes into Doctrine and the PHP world – I mean, properly
After that, we will face the biggest challenges so far:
- decoupling ODM, HTTP binding and Query Builder into 3 separate libraries/repositories
- refactor a big portion of the codebase according to the feedbacks from the Doctrine community
- implement persistence (from POPOs to DB)
I’m pretty sure the next months will be productive, intense and full of changes, but I’d realy like to suggest you one thing before leaving you: use this library.
Even though the ODM is not finished yet, HTTP binding and Query Builder are already at a stable stage: the first one is already faster than the binary-protocol implementation, while the second one is a very convenient library to help you saving a lot of time when writing OrientDB’s SQL+.
Again, their level of maturity is pretty high, and we accept and review bugs/feature requests pretty fastly.
So, what? Now, there are no more excuses.