Drupal.org downtime: 31st of October 2013, 15:00 UTC (08:00am PDT)

Form API is an extension of Render API and has got nothing to do with the DB. Don't know what you're on about then. Did you mean to mention the Entity API, which includes creation/form logic? That does have clear separation.

I mean to say that there is no separation what so ever between the html and php code. If I want to modify a div, to make it bigger, or smaller, many times I need to go into the php code to find the shitty form api element and modify in php code. This is the worse way to develop for web. And if I want to use the templates, to skip the form API, the Drupal way strongly discourages this.

No. We're moving in circles. I get your backward compatibility point, and I said from the beginning that Drupal can do more in that department. Again, you gave a very specific example which doesn't bear any weight. Talking about backward compatibility of the Node, Taxonomy and comment modules would be interesting. And in those cases it's near impossible to be backward compatible, as those use the new Entity API

Why would it be impossible? It's not just the drupal_json_output function. There are a lot of functions which changed the name just for the sake of changing name. And this is moronic to say the least.

I don't know how I gave you that impression. I said that anecdotal evidence is not evidence, which is in no way a contradiction nor a confirmation of your argument. In fact I know the documentation of the db_* functions and I think that @see explains what you need to know. What's your point? In D6 there was no $options parameter! Examples are plentiful, if you just care to have a look under the 'calls to X()' section.

Again, I was admitting that the docs for D7 are getting better. But the calls to X is not an example. That's not showing how to use it. It's just a convenient way for the creators of the docs to just finish their job quickly. Nothing more. Again, see the doc for the Qt framework.

Oh I understand just fine. Just look at the docs for hook_schema. And then look here (notice the foreign key definitions?): https://api.drupal.org/api/drupal/modules!node!node.install/function/nod...

Oh, but I really think you don't. Also, the fact that is in some code file does not make it a foreign key.

show create table node;

CREATE TABLE `node` (
  `nid` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The primary identifier for a node.',
  `vid` int(10) unsigned DEFAULT NULL COMMENT 'The current node_revision.vid version identifier.',
  `type` varchar(32) NOT NULL DEFAULT '' COMMENT 'The node_type.type of this node.',
  `language` varchar(12) NOT NULL DEFAULT '' COMMENT 'The languages.language of this node.',
  `title` varchar(255) NOT NULL DEFAULT '' COMMENT 'The title of this node, always treated as non-markup plain text.',
  `uid` int(11) NOT NULL DEFAULT '0' COMMENT 'The users.uid that owns this node; initially, this is the user that created it.',
  `status` int(11) NOT NULL DEFAULT '1' COMMENT 'Boolean indicating whether the node is published (visible to non-administrators).',
  `created` int(11) NOT NULL DEFAULT '0' COMMENT 'The Unix timestamp when the node was created.',
  `changed` int(11) NOT NULL DEFAULT '0' COMMENT 'The Unix timestamp when the node was most recently saved.',
  `comment` int(11) NOT NULL DEFAULT '0' COMMENT 'Whether comments are allowed on this node: 0 = no, 1 = closed (read only), 2 = open (read/write).',
  `promote` int(11) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether the node should be displayed on the front page.',
  `sticky` int(11) NOT NULL DEFAULT '0' COMMENT 'Boolean indicating whether the node should be displayed at the top of lists in which it appears.',
  `tnid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'The translation set id for this node, which equals the node id of the source post in each set.',
  `translate` int(11) NOT NULL DEFAULT '0' COMMENT 'A boolean indicating whether this translation page needs to be updated.',
  PRIMARY KEY (`nid`),
  UNIQUE KEY `vid` (`vid`),
  KEY `node_changed` (`changed`),
  KEY `node_created` (`created`),
  KEY `node_frontpage` (`promote`,`status`,`sticky`,`created`),
  KEY `node_status_type` (`status`,`type`,`nid`),
  KEY `node_title_type` (`title`,`type`(4)),
  KEY `node_type` (`type`(4)),
  KEY `uid` (`uid`),
  KEY `tnid` (`tnid`),
  KEY `translate` (`translate`)
) ENGINE=InnoDB AUTO_INCREMENT=29535 DEFAULT CHARSET=utf8 COMMENT='The base table for nodes.'

Please notice that the engine is InnoDB (so don't tell me that my db layer does not support foreign keys) and still no foreign key. Again, only the foreign key keyword in the creation of the table makes a foreign key. That's it. You could say that that is a foreign key, write it in 1000 php files, in 1000 text files, in 1000 docs. Still, if it is not in the DB, it is not a foreign key.

Clarification needed. When you have drush eval, the Devel module and other possibilities to directly access the Drupal API, why would you browse through PHPMyAdmin for CRUD operations?

For example, when I need to do complex views that take to long to run. I really think that the Views module is one of the good things in Drupal. But sometimes the queries would just take too long. In this case I usually use the View XML module (to take advantage of all the formatting options offered by the view module) to create my own optimized query. This way I am able for example to reduce the running time of a view from 2 minutes to 2 seconds.

And they are also other situation in which I need to go directly in the db. For example when a module does only do 80% of what I want it to do. In order not to modify the module code, sometimes I prefer to go and do some operations manually in the db.

Also, if you check the code of the taxonomy_vocabulary_delete (https://api.drupal.org/api/drupal/modules!taxonomy!taxonomy.module/function/taxonomy_vocabulary_delete/7) you'll notice that this is far from optimum. A foreign key would've make it far more rapid.