[wp-hackers] Active Record / ORM enhancements discussion for WPDB class

[Jacob Santos]

Well part of it is whether we should continue working on EzSQL library
renamed to WPDB or if we should, at which time PHP5 is required, change to a
new library and adapt the WPDB class to that new library. This would require
minimal testing and provide backwards compatibility with minimal time,
effort, and testing. Also, the new library would be maintained by a
third-party with some (little to no) support from the WordPress team.

The reason I propose this is that a lot of the code within WordPress is
similar. Most of the database calls are CRUD in one form or another. Each
time a new API is proposed with new tables the same code has to be rewritten
to match the new requirements and table.

In some ways, the insert and update methods of WPDB were added to change
that, but what I suggest goes a little bit deeper. If you unify the codebase
on CRUD or BREAD or Browse (multiple rows), Retrieve (single row), Edit, Add
and Delete, then it will handle common SQL for you. Granted, the majority of
what the API does is far more complex than those simple queries, but it
unifies how it is done.

Also, when you can have a base iterator, it removes some complexity. The
advantages of Active Record are few and given what WordPress does, would
only be standardizing what WordPress currently does. It would also be adding
maybe one or two more methods to WPDB, until PHP5 comes around and Iterator
support can be added.

The magic I believe, is with ORM, and given the links between tables may
simplify certain things.

For example, you desire post metadata, well, using DMZ CodeIgniter, you
would do the following: $posts->posts_metadata->get(); and you would only
get the post metadata associated with the current post. Is it better than
the current API? Not yet, but when you have multiple interactions, it
becomes increasingly useful and saves quite a bit of code.

Using DMZ, you would save quite a bit of lines of code because the
relationships will create the joins for you, instead of requiring an API
method or function to exist that does the joins for you manually.

API should focus on the more advanced cases of handling what normal
programmers either don't want to keep coding, or many novice programmers
can't easily do. Or save time and make complex tasks easier.

Backwards compatibility is simple really, given a new API that is
encapsulated around the old code.

Really, given what I'm thinking about, we can continue the old 1.x branch of
EzSQL and fork to WPDB version 2. Also, sadly, we can extend it to where
another class handles the connection and query functions allowing for
another DB to be managed by just calling: $wpdb->change_db_adapter(new
My_PDO_WPDB_Adapter());. Requiring that anyone wanting to change DB support
by using an entirely new WPDB class didn't ever seem wise. The Active Record
and ORM generally also abstract the SQL away, allowing for independent DB
queries to be made. Even if the change_db_adapter() was made, the problem
would remain that the new DB adapter would have to change the hard coded
queries to fit with the new DB.

Depending on what exactly new features we want, then that should really
decide what decision is made. All of this can be added to WPDB, but I think
if ORM is requested that a third party library is used instead.

On Thu, Jul 15, 2010 at 2:40 PM, Peter Westwood <peter.westwood at ftwr.co.uk>
 wrote:

> Personally I find nothing broken or disruptive to use with what we have.
>

Here are three:
WPDB - Reason: God Object restricting database access to single DB.
WP_Rewrite -> WP -> WP_Query - Reason: Controller implementation dependent
on and primarily for WordPress.
Procedural CRUD redundant functions for each API (posts, taxonomy, metadata,
etc) - Reason: Design decisions early on forced primary focus on single
functions for each task.


> Time spent re-inventing what we have to use new wizz-bangs / patterns / ...
> that are now more accessible doesn't make keeping everything backward
> compatible easier - in fact it makes it harder.
>

I don't believe that is true. Once something is deprecated and uses the new
code, as long as the old behavior is maintained in the new code, then the
old code no longer is required to be maintained.



> Developer time is a limited resource even with the 100s of regular
> contributors - all that time is best spent on incremental improvements
> rather than re-inventing wheels
>

This is true. The inclusion of new code, regardless of how well it was
initially tested will require many more fixes and time allocated to it after
the first few releases. Also, given the initial release of the new feature,
enhancements from interested parties will also increase the time required to
maintain those patches flowing in.

Focusing instead on fixing the new feature as opposed to fixing bugs in old
features is a problem and has been a problem since long before I joined the
community. I don't see how one person spending time largely on these things
will require the entire portion of the available contributors. Most of the
new features only require a fraction of the available contributors
regardless and may even bring in new contributors looking to correct
problems.


> In you want to go a try working on a WordPress like project that is built
> from the ground up using these newer techniques then you might want to
> investigate Habari - alot of the good folks that work on that are WordPress
> alumin and I believe it has a similar flow but is much more 'PHP5'
>

Giving you the benefit of the doubt, because I believe you are being
facetious. If not, then I would ask that you give me the benefit of the
doubt and not give an elitist response before all the information is given.
It would be better just to say, "Yeah, I'm never going to support this,"
then to tell me to go away and play in that other sandbox.

Jacob Santos