webschuur.com

I tweeted too fast, and wrong:

Site were the Dutch Government accidentally leaked its 2012 budget, is a Drupalsite. Yes #Drupal does not secure its files. Drupal for govs?

The mayor news outlets in the Netherlands did not link to the leaking site, but instead to the site that carried (a mirror of the) PDFS that were leaked as well as background information. I followed these links, without researching if these sites were the actual leaking sites. This site they, instead, linked to, is a Drupalsite. The one with the unprotected files was not.

So much for not investigating a little myself! The site that leaked the file, was an ASP (.net?) site.

I am sorry for this misinformation. And as said, tweeted too fast, did too little investigation and that makes me look stupid. I am glad for those that told me my mistake. And because I got married the next morning, writing this errata took more time then is appropriate. Sorry for that too.

As a bonus, and to make things up a little, some common Drupal leakages that I helped fix in clients projects. Obviously I have responsibilities (and even a few NDAs) so I don’t give names and urls.

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