zOMGz this rocks! :-)

That said, upon further consideration the new constructors (db_insert(), db_select(), etc.) should probably not use the dbtng_ prefix, but just db_. That way, when D7 comes out modules using this backport module will already work with the new API without needing to rename all of their methods.

Comments

mikey_p’s picture

Which functions would you say should be left as db_ ?

I was thinking:
'db_insert',
'db_merge',
'db_update',
'db_delete',
'db_truncate',
'db_select',
'db_transaction',

Crell’s picture

That sounds about right. Basically any that are in DBTNG but not in DB-Classic, so that modules using the dbtng module have the least amount of work to do when upgrading to D7.

mikey_p’s picture

Status: Active » Needs work

Fixed, see http://drupal.org/cvs?commit=225544.

Now I just need to roll some docs to explain this.

sinasalek’s picture

I'm not completely agree with @Crell, it might causes confusion for Drupal6 modules' next maintainers and it's not really necessary. Upgrading db functions written with DBTNG is as easy as replacing the prefix , and we will have to do the replace anyway for the other functions which should use dbtn_ prefix.
The only advantage might be a bit ease when back porting D7 modules to D6.

mikey_p’s picture

@sinasalek I think the way it's split now makes the most sense. I'd say 95% of the use cases of this module are going to be using the query builder functions listed in #1, and if that is the case the DB calls should require 0 change to the code to update to D7.

sinasalek’s picture

@mikey_p , mmm, i see. i checked the functions list, you're right. Thanks.

mikey_p’s picture

Status: Needs work » Fixed

Marking this fixed. If anyone has any questions about how this is split or managed, look at the split script that I hacked together at http://github.com/shomeya/dbtng/blob/master/split.php.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.