[wp-hackers] Meta tables: Take 5

Mon Jul 27 07:17:45 UTC 2009

What is good is not requiring the user of the API to realize the DB table scheme or understand how the DB table works. I think the Taxonomy API is a good example, if the whole concept wasn't so difficult to understand in the first place. I think the better solution is to abstract the DB entirely from the API user and build the API that is built on top of it.

The problem I have with CRUD, is that it forces the developer to know the DB scheme or at least understand the scheme. It seems to be taking the easy way out, "Well, I could create an API that doesn't force the developer using the API to know anything about the scheme, but meh, I lika the shiny and don't want to spend too much time developing something."

In my experience, it requires the user of the API to know too much information is not important. Likewise, if the Scheme changes, then the API must change and all code that uses CRUD most change as well. If you are trying to create an API that doesn't require hassling the developer working on the API and the user of the API to keep up with the changes, then why use something that either puts the workload on the user ("Oh crap, the API breaks backward compatibility again because of scheme changes.") or on the developer ("Well, I could make refactor the design to where it doesn't suck, but doing so will either break backwards compatibility or cause me to work around a lot of my previous scheme and coding mistakes.").

As for the proper solution, I've yet to find one that doesn't suffer from similar flaws or new ones. BREAD suffers from the same reasons of CRUD. I've discovered that the architecture should be a layer on top of the DB that abstracts the table scheme as well as any changes. Looking at how WordPress implements wp_insert_post() and wp_update_post(), I can say that that is far better than any design I've seen and have so far implemented. Actually, I have sinced strived to implement my APIs like wp_insert_post() and wp_update_post() in that inserting into tables uses CRUD or BREAD (I'm not so sure ORM or the others are any better or worse, just solves a different problem or the same problem differently).

So the underlying DB implementation uses CRUD or BREAD or whatever pattern or fad everyone is using this year, but the API above it is not. So I suppose what I mean to say is that I'm not in favor of forcing the user of the API to use CRUD, but okay for the developer to do so in order to Get Shit Done and build an API that the user can understand quickly and easily.

I think at the end of the day, if the choice is Getting Shit Done or Getting Shit Done right, which also means never, then I'll choose to have something rather than nothing. Which is why I keep having to kick myself in an attempt to not say anything stupid and take away from something that in all regards is actually pretty kick ass.

Jacob Santos

On Sun, 26 Jul 2009 21:41:30 -0500 (CDT)
Mike Schinkel <mikeschinkel at newclarity.net> wrote:

> Jacob,
> 
> I'm curious; if CRUD is bad, what is good?
> 
> -Mike Schinkel
> Custom Wordpress Plugins
> http://mikeschinkel.com/custom-wordpress-plugins
> 
> ----- Original Message -----
> From: "Jacob Santos" <wordpress at santosj.name>
> To: wp-hackers at lists.automattic.com
> Sent: Sunday, July 26, 2009 10:24:20 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [wp-hackers] Meta tables: Take 5
> 
> Well, I think it is fine, except for object_id doesn't really have an explanation. Why not $id, instead? The problem is that it doesn't explain what the object part is, so it can be anything. It is the ID of the type you are looking for, so post, comment, category, etc. Why not just name it ID and leave out the question of what 'object' means. People understand what ID means.
> 
> I'm not trying to argue against CRUD, I just wish another pattern or architecture was choosen for WordPress. CRUD is very simple and quick to implement. I just shudder every time I see it within WordPress and within my own code (papa doesn't like spending forever on "proper" design). Therefore, I'm trying to not argue CRUD in a wierd way, but still say it sucks and I very much hate it.
> 
> Jacob Santos
> 
> On Mon, 27 Jul 2009 03:17:30 +0300
> scribu <scribu at gmail.com> wrote:
> 
> > On Mon, Jul 27, 2009 at 12:21 AM, Jacob Santos <wordpress at santosj.name>wrote:
> > 
> > > CRUD in procedural form. Alas, it seems flawed somehow. The look, the feel;
> > > The wonder about how to make it better. Is there such a solution?
> > >
> > > It seems a pity to look at something so beautiful in its simplicity and
> > > then ask why? What purpose is there to mock something that should be so
> > > clerished and loved and yet not provide another?
> > >
> > > Not that objects are any better, just better organized. A shame really.
> > >
> > > I do cry every time I see CRUD.
> > >
> > > Good work nevertheless. I hope you choose to name the parameters better.
> > > There is a concept called, "Self-documenting Code" that is just plain
> > > awesome in its beauty and soft skin.
> > >
> > > Jacob Santos
> > >
> > 
> > 
> > Thanks for the comment - very poetic, but not really helpful.
> > 
> > Don't know how I could rename the parameters to be more self-documenting
> > than they already are. Metaphors maybe? :)
> > 
> > 
> > -- 
> > http://scribu.net
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> -- 
> Jacob Santos <wordpress at santosj.name>
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

-- 
Jacob Santos <wordpress at santosj.name>