INSERT/UPDATE/DELETE API + drupal_drop_record()

patch reroll due to minor coding style update.

@moshe: May I have more information about the needs of postpone this issue? I can't see the different of this issue with drupal_write_record(): it just just to complete the existing handling. We need write record, and so as drop record? They are always a pair, isn't it?

I guess this is the correct order of priority of my concern about this issue. INSERT/UPDATE/DELETE API is just a bonus of drupal_write_record() (and drupal_drop_record() that I am now proposing).

BTW, as we are able to handle the query builder better within DB level, I can't see the reason of not implement it: they are handy enough, and won't break any existing code implementation; they are even transparency to normal developers if they use drupal_write_record() and drupal_drop_record() :)

1. I can't see why it is not strong enough: we are planed for drupal_drop_record(), but just miss it. The constant "SAVED_DELETED" is already preserved (common.inc: 25), and also used in taxonomy (taxonomy.module: 220) with very lossy coding style. We won't hope to use this constant without any helper function as abstraction, which similar to the case of drupal_write_record().

2. The demo for node_delete() show that we will able to handle the DELETE action as simple as using drupal_write_record(). On the other hand, ADD/DROP actions are always considered as pair. Without drupal_drop_record(), contribute developers may feel very confuse about this double standard (Add by handy helper function, but manually drop is required...)

3. Seems there is no direct relationship of this INSERT/UPDATE/DELETE API implementation with yours version: your version is target for PDO which should belongs to D7 (very robust, I really love it), but I am working for D6 which duel with existing database abstraction requirement. On the other hand, if this is something that we are able to implement with no pain (transparency, and just a split version of what drupal_write_record() does) even within current development cycle, I can't see a strong reason for postponing it :(

I think this issue is even "critical" now, as we are really miss out an important function (drupal_drop_record()) for standardize both the ADD/DROP handling, which will introduce confuse to contribute developers :(

@moshe: I think that should be different concern about drupal_drop_record() and INSERT/UPDATE/DELETE abstraction.

According to drupal_drop_record(), it is something that we are now missing, even it is not as important as drupal_write_record(). They should always considered as a pair-up handling with no question. Since it is just a clone to drupal_write_record(), I am strongly suggest about reconsidering its possibility within D6.

On the other hand, INSERT/UPDATE/DELETE abstraction should be consider in different way: if we feel not happy about this 3 simple functions, just not implement them, and let drupal_drop_record() alive in D6. They are just a bonus. BTW, according to existing founding of Crell, this abstraction is very meaningful which should be implemented (on someday, with some sort of implementation). Even it is scheduled for D7 with the help of PDO powerful "?" placeholder, my implementation is just what we needed for based on our existing database abstraction layer requirement. Moreover, we should even seems it as the "split" handling of query builder which is currently existed within drupal_write_record(): it is nothing special other than this.

Finally, they are all optional API, which similar as drupal_write_record(): we will not died even don't have drupal_write_record(), and able to wait for it in D7; but we let it be, based on many different concerns. We don't need to force anyone to use these new feature. It won't break any existing handling, and the use of helper functions (db_query_insert(), etc) are even transparency. They don't CHANGE any existing DB API. I am not blame on the slide in of drupal_write_record() (it is very powerful and handy, and I really love it, as the point of view of normal contribute developer), but I am confusing about this double standard of similar issue.

It sounds too pity if we need to wait for this until D7 :(

This is a simplified version without abstraction for INSERT/UPDATE/DELETE API. It add the missing function drupal_drop_record(), update some coding style in drupal_write_record(), and modify node_delete() as demo handling. The change is transparency to normal developers, which don't break any existing code implementation, but keep the write/drop abstraction as synchronized. Should we give a little bit love to it, in order to complete our existing handling?

Patch attached is the incremental change for adding INSERT/UPDATE/DELETE abstraction below drupal_write_record() and drupal_drop_record(), as a database dependent implementation. This can indicate clearly about how the bonus abstractions are able to simplify existing handling.

Please feel free to forget about this incremental patch if it is not suitable for D6, I will come back with this abstraction later. BTW, hope for a kindly reconsideration about drupal_drop_record(), as it is very meaningful to normal contribute developers.

Patch update via latest CVS HEAD, with some syntax tidy up. This patch is now tested for both MySQL 5.0.32 and PostgreSQL 8.1.9 on Debian etch 4.0r1 with PHP 5.2.0-8+etch7, passed with node create, revision update and delete (so both case for INSERT/UPDATE/DELETE). Feature benefit as listed above. Should be trivial to commit.

A complete "PLUS" version based on #14, with INSERT/UPDATE/DELETE abstraction. Completely tested as case above, passed with no error, and proved as a completely transparency implementation. Should also be trivial to commit.

Since D7 is now open for public development, this patch is reroll via CVS HEAD. The patch include:

• Add INSER/UPDATE/DELETE API: a simple abstraction which don't degrade any existing performance (please refer to a complete benchmarking result). On the other hand, it is very important for oci8 and pdo_oci implementation (please refer to a functional Oracle driver implementation).
• Add drupal_drop_record(). Synchronize with drupal_write_record() as a pair-up handling.
• Enhance drupal_write_record() with INSERT/UPDATE/DELETE API.
• Enhance cache_set() with INSERT/UPDATE/DELETE API, as an individual example.

Completely tested with MySQL and PostgreSQL.