Developer Blog

  • Blog
  • /
  • Published development versions of DB and ORM module for PHPixie 3
By Dracony on 24 January 2014

I found some time to push the current versions of DB and ORM modules to github.

You can find the 3.0 DB module branch on https://github.com/dracony/PHPixie-DB/tree/3.0 and the ORM module is available on https://github.com/dracony/PHPixie-ORM/tree/3.0.

As I said before the database module is pretty much done, apart from me still having to add in documentation comments. Another thing is support for the DISTINCT modifier which I need for ORM.

The ORM module is being rewritten entirely too. It will retain most of what you already got used to, but here are some new features that will be added (some are more or less already implemented):

  • Multiple strategies for different situations. For example if you are using tables in the same database the relationships will be processed using IN subqueries and joins, but if your model tables reside in different databases PHPixie will first extract item ids from one model and use them to query the other.
  • Ability to specify relationships between SQL tables and MongoDB collections. This is permitted because of the multiple approaches described previously.
  • You’ll be allowed to specify relationship conditions in a simple fashion. E.g. you can directly query deep relationship paths:php?start_inline=1 $query ->has('fairy.tree.location', 'forest') ->or_has('fairy.flower.name', 'Daisy') ->or_has('fairy.tree.name', 'Oak') - Relationship query optimization. The above query if using the multiple query approach would in other frameworks load ids for the fairy.tree.location condition and fairy.tree.name separately and would require you to rewrite this query in a different fashion (e.g. using callbacks) to prevent such behaviour. PHPixies ORM has a fully implemented optimizer to take care of this itself. Of course you can always groups conditions manually if you want to spare optimizer time.

And now something totally new, relationships won’t be defined inside classes anymore, they get a special configuration file for that. Also you won’t have to specify belong_to and has_many relationships separately. Instead you define familar oneToMany and OneToOne relationships like this:

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
//inside the config file
return array(
   array(
       'type' => 'oneToMany',
       'owner' => array(
             'model' => 'author'
        ),

       'items' => array(
             'model' => 'post'
        ),
   ),
   array(
       'type' => 'manyToMany',
       'left' => array(
             'model' => 'post'
        ),

       'right' => array(
             'model' => 'tag'
        ),
   )
);

//Obviosly these relationships allow a lot more options to configure,
//this is just a minimal setup.

Now isn’t that much more readable and simple?

comments powered by Disqus