Splitting of ArangoDB-PHP into core and higher level ODM

[frankmayer]

This is an issue to introduce and follow-up on the progress of splitting the ArangoDB-PHP client.

Introduction:
I am in the process of splitting the driver into core and higher level ODM`.
The core-client will provide connectivity to the API's provided by ArangoDB and the goal is for it to stay as light as possible without providing additional functionality.

All additional functionality will be provided by the higher level part.

This whole idea of doing this, is to provide a basic and light foundation where higher level implementations can be built upon.

For example: Doctrine ODM or a Laravel specific implementation

For special needs, instead of using the provided higher level drivers, one could also write his/her own driver on top of core

Please comment on this issue if you have any suggestions / ideas on this.

Thank you :)

[F21]

@frankmayer: How is this coming along? I have found some time to work on #32, but don't want to break anything you are doing :)

[frankmayer]

@F21 unfortunately now I got sidetracked by an urgent and very time-consuming project. Will not be able to do work on this for the next few weeks. :(

However, you won't break anything I do, as I'll have to refactor your code (and all other higher level) afterwards anyway after the split. :)

Waiting for your PR 👍

[F21]

Some more thoughts on this. How much backwards compatibility are you willing to sacrifice for the ODM?

I have been using gabodemooij/redbean for the last few years as my ORM to talk to MySQL and the API is very very beautiful and simple. Perhaps we can model the ODM after it:

//Create a new document from the users collection:
$user = ODM::dispense('users');
$user->name = "Batman";
$result = ODM::store($user);

So then, instead of having all sorts of methods, we are restricted to a few:

• store to save/replace/add
• dispense to create a new object representing a document from a collection
• find, etc to search and find beans
• An AQL function to run queries.
• Convert to object function to use on results of AQL queries (because people can return projections)
• A few methods to manage graphs/collections.

RedBean was designed to be "schema less" in the sense that it is not expected to model the whole database in a program before hand and I think this model is very suitable for something like ArangoDB.

What do you think? 😄

[F21]

Another interesting benefit is that currently the library is very "talkative" in the sense that if I save a vertex, edge look for a vertex or document, it makes a single call to the server.

However, if we can introduce some internal mapping, so that say, when we create a few vertices and link them via edges, they aren't sent to the server immediately. It is only when we save something, then all the connected things (vertices, edges) are then all saved in 1 go using a batch command.

[frankmayer]

Hi,
thanks for the link, I'll check that one out for ideas. 😄

Actually the new ODM will be walking in the old one's shoes. But as I mentioned in another issue, after the split it will be easy to build anything on top of the core client.

For example, I plan to have a different approach to the current client in my own client which I'll be releasing shortly after the split.

However the "original" client, should always be backwards compatible.
Users will then have a choice, to either use the original or any other that fits their preferences.

[F21]

How is this one coming along? Is there anyway I can contribute to the split? 😄

[frankmayer]

Hi Francis,

Sorry it took so long to get back to. I am still struggling with other stuff, but at least found a bit of time to release the 1.2.1 client and also implement 2 major new features for the 1.3 version. 😄

Looking into a project after having left it a bit aside for something else, is good for perspective. I'll be doing some more tests and research for now. The "splitting" of the client is unfortunately not that easy, if we want the core driver to be "really good" and flexible. I have tried a few approaches, considering flexibility and performance. I am still not through with testing stuff and it will surely take a bit more time.
The whole thing is easier said than done
Will be back with more info soon 😄

[frankmayer]

Given that ArangoDB is not widely used on shared hosts like MySQL for example, I was thinking of upping the minimum requirement of the new core driver to PHP 5.4.

Theoretically it's the best choice, because:

a) PHP 5.3 will enter "End-of-life" state, once PHP 5.5 will be out, within the next 2-3 months

b) PHP 5.4 is more performant in OOP and has some nice new features that make new things possible and old things easier, like:

• Closures now support $this
• Short array syntax, e.g. $a = [1, 2, 3, 4]; or $a = ['one' => 1, 'two' => 2, 'three' => 3, 'four' => 4];
• Function array dereferencing, e.g. foo()[0]
• Class member access on instantiation has been added, e.g. (new Foo)->bar()
• Traits. Not necessarily to be used, but nice to have as an option.

c) We can still keep the classic ArangoDB-PHP up-to-date with new developments up-to a reasonable point, for people still running PHP 5.3

d) People really need to move on 🚀, instead of being glued to the dead stuff 💀 ...

What do you guys think?

[F21]

@frankmayer

a) and b) I totally agree! PHP 5.3 users have been recommended to upgrade to 5.4 for quite a while now. Now that PHP 5.5 is on the horizon, 5.3 would be EOLed, so there is simply no need to support 5.3

In addition, as you mentioned, ArangoDB is not on shared hosting (I haven't seen any myself and don't expect to, similar to how there really aren't any nginx shared hosting around), it makes sense to be able to dictate a higher PHP version.

c) Yes this is possible, just like what we have been doing now. However, does this mean we will need to maintain ArangoDB-PHP Classic and ArangoDB-PHP Core and ArangoDB-ODM, since ArangoDB-PHP classic uses PHP 5.3?

Another thought: What if we use Paradox as the new ArangoDB-ODM? This should reduce the work load for the split some what 😄 The plan was to move Paradox to the core driver once that has been released 😄

d) Fully agreed 👍

I would like to contribute to the core driver 😄 What if you uploaded your current code base to a repo so we can all work on it together and plan for required and new features? 😄

[frankmayer]

@F21

a & b) If @jsteemann also agrees with my proposal, I'd say we move on to 5.4 requirement for the first version of ArangoDB-Core and the associated ArangoDB-ODM version. It will also run a bit faster due to the improvements in PHP 5.4 & we'll probably can make a few performance adjustments in time.
BTW, PHP 5.3 EOL will be announced with the final release of PHP 5.5, and will then only receive security fixes for a year,

c) I'd propose, we only do bug fixing, but not new features on the classic ArangoDB-PHP driver, unless there's is really a big need from the community to add features. But in that case, the needing community could probably contribute new features themselves to the old implementation 😄 (I guess that's incentive enough to change to PHP 5.4 😄)

Finally, when you (@F21) wrote your last comment, the Core code I was working on was a pretty mess because of a lot of testing and stuff. However, now I am done testing 😄 I am now in preparation of an initial Core repository. Fruits of this preparation have already found their way into the classic driver (see Cleaning spree 😄 )
I will work on the initial core repo over the coming weekend and commit it as soon as possible, so that you can also contribute to it.

The way I see Paradox (and also my own work in progress 😄 , as soon as the Core and new ODM is released), are as alternatives to the official ODM.
The new "official" ODM should remain the same in its conception and a user should be able to only do an in-place upgrade.
I envision that the new ODM version should work the same out of the box, as with the old driver.

[F21]

Awesome! I look forward to being able to work on the core driver 😄