Interesting project but I wouldn't choose it

This library fails on two aspects:
1. It is not tiny - it has 13 classes not including tests.
2. Its not really an ORM - by default it stores the retrieved data in arrays, and there's not automatic object loading: you have to write the select statements yourself and there is a lot of boiler plate code even if you want to do very simple things like load a single object, update it and store it back.

For a really small ORM (but a real ORM), check out Potato ORM - https://github.com/andela-cvundi/potatoORM .

It has only 6 classes, 4 of them are just semantic exceptions - so there really are only 2 code classes. If you just need to load some objects and store them, there are only a couple lines of code:

$user = User::find(2);
// update fields
$user->update();

My library serves my purposes:

1) Multi-database
2) Multi-backend
3) Has a handy Query-object

With tinyorm I am able to perform CRUD operations on an entity using various backends. Can you do the same with any other similar tool?

And, I did not count classes. To me, it's small enough ;-) As for the amount of code, it's really a matter of choice. It would be nice to say User::find(5) and get a User instance in return. For me it's important, though, to specify particular way I want the User object to be retrieved.

However, I will probably think of a possibility to add static methods for CRUD operations into Entity. It does seem to be possible, actually.

After having a thought on conveniency subject, I decided to add Entity::find(), Entity->save() and Entity->delete() methods. In order not to have to pass a persistence driver instance to every such call, I also added Entity::setDefaultPersistenceDriver(). Given that you issue a call to Entity::setDefaultPersistenceDriver() in your app bootstrap, you can write code like this:

$user = User::find(3);
$user->name = "John";
$user->save();

I think you are going in the right direction :-)

IMO, the point of an ORM is allows you to treat table rows as objects and do day to day stuff without thinking about connectivity and queries too much (or at all), even if you do moderately complicated stuff like loading a list of rows referring a row you already know (see Kohana ORM's "has_many" relationship).

I believe you can achieve most of your goals (including working with multiple presistency providers) without poking at dangly database bits (again, see Kohana ORM).

Now you only have to solve the "tiny" part of your library...