webschuur.com

Here comes a very short, cut-down version of relations.inc. It is a very basic api for use in various indexing schemes.

It can be expanded to hook into db_rewrite_sql(), but I refuse to do that for the sake of my remaining sanity.

The basic idea is that modules can/should use this or analogous api to perform all “relation” queries.

There is a HUUGE confusion going on about What is a relation?, but I won’t participate in that any more - no time, sorry.

I decided to split the relations api from the more advanced issues realted to the current sqlgen implementation. The main reason for this split is due to the never ending discussions about what is a relation on drupal forums, irc, mailing lists, etc…

The relations api is going to be a simple implementation of a tree and graph indexes, with emebeded SQL. You should be able to do things like - get related nodes; get next, previous, parent, children, sibling nodes.

Long term-wise we should be able to replace the book and taxonomy implementations of the database using this api. I’m intentionally going to make it extremely minimalistic, since I’m really not a supporter of using embdedded sql statements.

read more

minor imporvements - Rev 4 - vlado (2 file(s) modified)minor imporvements
[relations svn]

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.

sqlgenjoin(
// functional form
sqlgentable('n'=>'node'),
//array(ish) form
array('r'=>'noderevisions'),
// the join constrains, defines the new relation
sqlgenconstraints(
array('noderevisions'=>'may be null'),
sqlgenand(
sqlgeneq( arg('node','nid'),arg('noderevisions','nid') ),
sqlgeneq( arg('node'=>'vid'),arg('noderevisions','vid'))
)
),
//result filtering
sqlgencond( sqlgeneq(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('noderevisions','nid')),
array('#op'=>'eq',
array('node','vid'),
array('noderevisions','vid')),
array('#op'=>'eq',
array('node','nid'),
'#param'=>'nodeviewid')
)
);
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

read more

I’ve been reading. Scheming. And I stumpled upon SchemeUnit and SchemeQL: Two Little Languages. I liked the paper. Especially the SchemeQL part. It does state my (intellectual) motivation behind writing relations/sqlgen.

• SQL statements are not checked until execution time. That is error prone.
• SQL statements are not host language statements. They can’t be used in the same way or manipulated as the host language statements. Except by using crude text processing, one cannot programatically compose, abstract and refine embedded SQL statements. Code quality and productivity suffers.

read more

I realised that I need to demo, coming soon in flesh, why I’m doing the relations the way I do, and why I have these strange concepts.

Let’s start with an example in KIF, the example is lifted from the KIF draft proposed American National Standard (dpANS).

(defrelation number (?x) := (or (real ?x) (complex ?x)))

What does it mean? Well, is number(x) will be true if x is either a real or complex number. Number is a relation.

Generally speaking we have two ways to define a relation or function - either explictly defining all possible/known cases, or by using some procedure to produce them.

read more

I’ve updated the code in my relations svn repository.

Some of the changes a very experimental - like the munit.inc - it is implementing bovine tests- simply very basic (beasty), non-complicated, dirty, grazing unit tests. When I was writing the tests I was out of net reach, so no simpletest for me. And now I just like it.

Implemented tests for the majority of sqlgen. There are the beginnings of theme widgets - using drupal forms api for theming, as Adrian suggested earlier. The widget tests need to be refactored. Don’t you believe them.

What I need to do next is to figure out how to tie together the data from db and some meta-data so I can generate the different view. The main goal is minimal metadata for maximum impact. We shall see. At the moment nothing more than the table description from db is used.

read more