[wp-hackers] Meta tables: Take 5

Mike Schinkel mikeschinkel at newclarity.net
Mon Jul 27 14:57:03 UTC 2009 

Thanks for that long answer, but I still did not hear a viable  
alternate to CRUD, only some hypothetical panacea.

In my development experience (which spans 20 years now) I've gone from  
strong believing in abstracted solutions to learned belief that  
abstraction for abstraction sake is bad and it's better to stay closer  
to the metal unless and until a true pattern emerges. When that  
pattern dies, it should ideally implement in the language (i.e. the  
"foreach" iteration pattern vs. "for" with counter variables) or it  
that can't happen then in language's library or lastly in a framework  
like WordPress' core.  As far as I can see, the only true pattern  
visible is CRUD.  Something better may come along but I have yet to  
see it.

Simpler is better.

-Mike Schinkel
WordPress Custom Plugins
http://mikeschinkel.com/custom-wordpress-plugins/




On Jul 27, 2009, at 3:17 AM, Jacob Santos wrote:

> 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>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list