DBTNG: Menu module

Attached is a first patch, mostly static queries..

A few notes:
- I used fetchAssoc() and while (instead of foreach) all over the place because of: #423690-2: menu_link_maintain(), $op update critically broken.. I'm not sure if comment #3 of there would be the better approach.
- There are multiple range(0,1) queries which are just used to see if there is altleast a single row. Not sure if we can replace these with static queries..
- There were multiple "half-converted" queries, which missed the ":" in the key of the arguments array. It seems that one is not necessary, but I added it anyway to have it consistent

Edit: Phew, that patch is leet... "13.37 KB" ;)

- Converted those db_delete() calls to multi-line
- Removed the range stuff from those two queries in menu_node_prepare(). I don't think they're needed and save us two db_select() calls.

Based on discussion and benchmarking,

Is seems to be quite a bit faster to do this (or to set the fetch mode in the db_query() call):

  $result->setFetchMode(PDO::FETCH_ASSOC);
  foreach ($result as $m) {
    ...
   }

versus:

    while ($m = $result->fetchAssoc()) {
      ...
    }

see: #430986: Compare DB fetch options for speed.

Updated to use setFetchMode and foreach

Instead of calling setFetchMode(), other places in core the queries are called like:

$result = db_query($sql, array(':name' => $menu['menu_name']),  array('fetch' => PDO::FETCH_ASSOC));
);

or:

 $query = db_select('book', 'b', array('fetch' => PDO::FETCH_ASSOC));

probably some of the complex queries shoudl be converte to db_select()?

- Re-rolled
- Updated FETCH configuration
- Queries should only be dynamic if they need to, afaik.

possibly this one query should be db_select():

    SELECT m.load_functions, m.to_arg_functions, m.access_callback, m.access_arguments, m.page_callback, m.page_arguments, m.title, m.title_callback, m.title_arguments, m.type, m.description, ml.*
    FROM {menu_links} ml LEFT JOIN {menu_router} m ON m.path = ml.router_path
    WHERE ml.menu_name = :name
    ORDER BY p1 ASC, p2 ASC, p3 ASC, p4 ASC, p5 ASC, p6 ASC, p7 ASC, p8 ASC, p9 ASC";

But overall looks good.

The second example is actually two arrays and each of them does only have a single value. I agree that the line is too long, but how should it be broken up?

Re-roll with some minor improvements.

Quick code-style question: Is it okay to put strings (ie. SQL queries) in double quotes if this is not made necessary by single-quoted strings inside the queries? Your patch uses double quotes for all queries.

Coding standards doesn't make an explicit ruling, but recommends using single quotes wherever possible.

Wow, that's a big failure. Almost a third of menu module fails.

Hum. I should it test locally before submitting the patch :-/

@Arancaytar:
The DBTNG Documentation can be considered as "DBTNG coding standards guidelines", and http://drupal.org/node/310072 always uses double quotes.

Mixed up :name and :menu parameter names.. renamed all of them to :menu to be more consistent.

Somehow I thought db_query_range() was deprecated?

Me too, but.. #391340-59: Job queue API

Re-roll of the above patch, no changes.

Committed to CVS HEAD. Thanks!