[wp-hackers] Meta tables: Take 5

Mike Schinkel mikeschinkel at newclarity.net
Mon Jul 27 15:25:04 UTC 2009 

LOL, what a typo!

"When that pattern dies, " should have been "When that pattern does  
(emerge), "

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




On Jul 27, 2009, at 10:57 AM, Mike Schinkel wrote:

> 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
>
> _______________________________________________
> 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