Database

I've heard various rumblings in #drupal from people who don't like the current DBTNG code style for one reason or another. Since PDO doesn't have coding standards, we've had to make up our own. Complaints range from it being inconsistent (which wouldn't shock me, since it was decided sort of piecemeal between random conversations between Larry and myself) to not being easily formatted in tools like Coder Format and emacs (which is a big problem) to just being kind of "icky." Not having this nailed down is actively blocking issues such as porting core files to DBTNG.

So let's have it out! Here's the current syntax. Can you do better? And why?

With Drupal 6, menu tokens are able to automatically load database records given an object id, this is a great feature, however this requires developers to implement 'load functions' for loading their records. Those 'load functions' are often just a wrapper around 'SELECT * from {mytable} WHERE mykey = %d'.

We could do better, and allow automatically load operations, and even better, enable automatic basic CRUD.

Drupal 6.x. Table "node".

What should the value of the "language" field be if the displayed text is Chinese.

If a value is required, are there any other things that need to be done so that Chinese symbols are correctly displayed.

Any help appreciated.

Steve
http://prime357.org

ps. I've got a thread running at my site which I think this may be a part issue to it. As you can imagine it's becoming very confusing as all I see is either unicode or Chinese symbols (can't read Chinese).

I hope this is the right area for this question which refers to the 'thread' field of the table 'comments'. I provide a non php solution to convert Wordpress data to Drupal. I recently became aware that the thread field is not a string of decimal numbers but is in fact a string of base 36 (Vancode) numbers. I've created the necessary functions to convert to and from base 36 format but I'm a little confused re - the leading digit/character.

Here is an excerpt from http://api.drupal.org/api/function/int2vancode/5

<

blockquote>

I start my Drupal + Oracle research since the end of Drupal 4.7 life cycle (around Oct 2006), based on my client's request. The project is still running, but I am not satisfy about its progress. After keep trace in Drupal database stack implementation for more than years, it is time for focusing on Drupal 7.x development.

So what are the changes since 4.7.x? And what will be happened for 7.x? I would like to share my research progress with you, and so let's brain storming for what's next :-)

I'm assuming it's too late, but if not here's an easy performance win for D6:

http://drupal.org/node/215080

<

blockquote>The type column of the {system} table is currently a varchar(255) field. Yet in 99% of all Drupal installations it stores either the text 'module' or the text 'theme' and nothing else. This is already a strong case for making it an int column and defining constants for module and theme. Then, on every page, there is this query:
SELECT filename FROM system WHERE name = 'user' AND type = 'module';

I think it is safe to say that many developers already using or about to start using MySQL table type InnoDB. Some developers even changing default MySQL storage engine to InnoDB.
In many cases it make sense to convert table type if not for all tables, then at least for some tables.
In this situation will be nice if modules developers will state what table type is necessary for those modules and why.
Otherwise, its has to be investigated and tested for all modules in the project installation. May be it is fun but it is also a lot of time.
My suggestions for Drupal developers are

• include into modules .install file the indication of MySQL table type in the end of each table creation query like "CREATE TABLE `tablename` (...) ENGINE=InnoDB DEFAULT CHARSET=utf8" or "... ENGINE=MyISAM ...";
• include into 'INSTALL.TXT' file description of why these tables need to have those types.

That will give another developers enough information for making right decision on MySQL optimization of project's Drupal installations.