Since I am actively playing around with it, I
wanted to share some snippets to use the
Doctrine OrientDB ODM
in your PHP applications.

Prelude

In the last few weeks I’ve started working,
for fun and profit, to a personal project,
nothing really exciting as of now.

The thing is, since I wanted to get back on some
cool piece of software, I decided to go for
OrientDB for the persistence and a
mini-framework a-la Symfony2 as foundation for the
PHP application – I actually considered NodeJS first,
but I need a prototype in 2 months so…

Point being, I’d like to share with you my basic
approach to the OrientDB ODM.

The container

Given I’ve been inspired to Symfony2,
instantiating the main ODM classes
happens in the DIC:

the Manager, which requires a Mapper and a connection to
OrientDB through a binding class implementing the
Doctrine\OrientDB\Binding\BindingInterface

the Mapper, which requires a directory where it can write
proxy classes (for lazy loading), and an annotation reader
(this is not required, I’ll explain it later), plus a source
directory to locate entities

the HttpBinding, used by the Manager, that does raw
queries to the OrientDB server

the Annotations\Reader

a cache implementing the interface Doctrine\Common\Cache\Cache:
in dev environments it is needed since ApcCache is the default
one, and you would need to flush APC every time you change an
annotation in your entities (we will probably change it and put
ArrayCache by default, so that you will need to tweak the live
environment, not the dev one)

Autoloading

The autoloading is straightforward, thanks to the PSR-0; the
only thing that you should keep in mind is that you will need
to specify a separate autoloader for proxy classes, since they can
be generated wherever you want (ideally, in a temporary folder,
since they should be removed every time you deploy):

As you see, mapping an entity is pretty easy:
the first annotation is at class level, to define
which OrientDB classes are mapped by the entity,
then for every property that you want to be
persisted / hydrated, you define another annotation and
public getters / setters; if you want the property to be
public, you dont need getters / setters.

<?php// find all users$userRepository->findAll();// find one user given its RID$userRepository->find($rid);// find all users with the nick "overlord"$userRepository->findByNick("overlord");// find the user with the nick "TheOnlyOverlord"$userRepository->findOneByNick("TheOnlyOverlord");// find jack's wife$jack=$userRepository->findOneByName("Jack");$wifey=$userRepository->findOneBySpouse($jack);// spouse is an attribute of type "link"

and it’s not over, since you can, of course, add
custom repository classes.

Custom repositories must be located in the entity’s folder
and follow the naming convention EntitytheymapRepository:
for our User entity, we would need to create a UserRepository
class in %base-dir%/src/PROJECT/Entity/:

Can I haz raw queries?

Entities and repositories are good, but what about
adding some SQL+2 to the mix?

That’s very easy, thanks to the query builder
that’s packed with the ODM:

Example queries

123456789101112131415161718192021

<?phpuseDoctrine\OrientDB\Query\Query;// instantiate a query object$query=newQuery();// simple SELECT$query->from(array('user'))->where('nick = ?',$nick);// throwing some spice into the mix$query->orWhere('attribute = ?',$attribute)->orWhere('(this IS NULL OR that IS NOT NULL)')->limit(10)->orderBy(...);// SELECTing a single record$query->from(array($rid));// SELECTing two records$query->from(array($rid1,$rid2));

When you manipulate the $query object you are basically
creating an SQL query with an object-oriented fluent interface;
to eventually execute the query, just pass the object to
the Manager:

I would not advise you to install one of the old tags,
or even the last one, which brings the namespace
changes for the incubation in the Doctrine
organization, but to install it directly from master
via composer:

1

"doctrine/orientdb-odm":"dev-master",

as we are constantly doing bugfixes and so on
(I would day you would get an update – at least –
every week).

That is it, now start playing around!

Notes

Be aware that if you are retrieving a property which is NULL in the DB and you don’t declare it as NULLable, an exception will be thrown (and there is an issue to improve the exception message https://github.com/doctrine/orientdb-odm/issues/152) ↩

OrientDB’s QL is called SQL+, as it looks like SQL but has some major improvements, as it’s very developer-friendly ↩