We are not like that currently. We are driven by forms. We are freely mucking with database tables belonging to other modules. Following David Strauss' call, I made sure that in Drupal 7, fields can be stored anywhere, not just SQL. Think CouchDB or Amazon SimpleDB.

This has vast consequences. As you do not have any idea about the storage, you can no longer just throw a SELECT on it, you must go through the API, there is no other way. And this puts a big big burden on the core developers: if we do not provide some API, we are in trouble. But, we are working on these issue. The current biggest issue was raised by Damien in DrupalCon DC and today I have a very good example. Let's suppose that node 123 and node 124 both belong to term 987. Currently you can run a query on term_node table, filtering on tid=987 and get 123 and 124 back. In current HEAD, you can currently pass in an object type (node) an array of objects (node 123 and 124) and get back that the taxonomy field has a value of 987. However, there is simply no method where you can ask "I need the entities where this taxonomy field value is 987". We will get this issue solved sooner than later. But it clearly demonstrates a vast change: we need to think through what do we want to do with fields. With tables, if we forget a way of usage, all is needed an index which is a minor update. With APIs, this needs a new function, a major change.

Also, I am working on a queue module and people wanted a job scheduler and initially I simply refused because again I want pluggability (think Amazon SQS) and then you are limited to what your API can do. Of course, I did figure out finally (and Alex Barth coded an initial version) of the job scheduler based on this API.

Commenting on this Story is closed.