As it says on the box minor improvements. Actually the changes are a mockup of some of my ideas for better/proper database abstraction, and a variation on some of Adrian's model thoughts.
sqlgen_join( // functional form sqlgen_table('n'=>'node'), //array(ish) form array('r'=>'node_revisions'), // the join constrains, defines the new relation sqlgen_constraints( array('node_revisions'=>'may be null'), sqlgen_and( sqlgen_eq( arg('node','nid'),arg('node_revisions','nid') ), sqlgen_eq( arg('node'=>'vid'),arg('node_revisions','vid')) ) ), //result filtering sqlgen_cond( sqlgen_eq(arg('node','nid'),$nid)) );
This is the functional form. It provides a good abstraction. It is independant of the underlying structure. In my opinion it has better code readability. Can be thoroughly unit tested.
$view=array( '*'=>'node_revisions', '*'=>'node', 'name'=>'user', '#cond'=>array( '#op'=>'AND', array( '#op'=>'eq', array('node','nid'), array('node_revisions','nid')), array('#op'=>'eq', array('node','vid'), array('node_revisions','vid')), array('#op'=>'eq', array('node','nid'), '#param'=>'node_view_id') ) );
The array form, can easily become a mess. It is faster using arrays, rather than using functions to generate them, but could be daunting.
Both cases provide a close native equivalent to s-forms in php. Although you have eval(), the native php syntax is not as easily manipulateable as in lisp.
Still both forms have a significant advantage over 'embeded SQL'. We can get native php expression of the concepts in the db. We can optimise the queries, based on both data knowledge and database backends. Database independence is obvious. No rewrite_sql hacks. So things like coding a new/custom permission system becomes a breeze. Content type mashups, view/form remixing becomes possible.
As I've said this is just a mockup.
updated the comments in the functional form for readability