Posted by Manuel Lemos on 09/29/24 11:27

Hello,

on 09/20/2005 10:04 AM Michael Sims said the following:
>> This is not to trivialize your Metastorage project (or, to be more
>> accurate, I know nothing about it, so it's not my place to trivialize
>> it or otherwise), but to point out that 'out-of-the-box' solutions to
>> fundamental coding development problems probably ultimately makes for
>> a poorer programmer. I could well be wrong, but it seems this is a
>> case of "give a man a fish" as opposed to "teach a man to fish".
>
> I see your point, but I'm not so sure I agree fully. Manuel suggested
> Metastorage (which makes sense, it's his project and he's most
> familiar/comfortable with it), I suggested Propel because that is what I've
> used. I think we both suggested existing ORM's for the same reason...
> namely that properly implementing a full featured ORM is an extremely
> difficult thing to get right. I don't know anything about Chris's skill as
> a programmer, but he's bound to reinvent the wheel several times over, and
> poorly to boot. I believe that implementing an ORM is one of those things
> that you cannot fully understand and appreciate until you've tried to do it
> and failed. IMHO it's only after you've built one that you realize what you
> really need, and by then it needs to be rebuilt. It's kind of like Fred
> Brook's "plan to throw one away; you will, anyhow", or at least it was for
> me.

Right, I could not have said it better, especially the part about people
that prefer to break their heads trying to do something that others have
done, providing much more mature solutions.

I am including myself in that group of people. 3 years ago I started
developing Metastorage but only after have looked at several solutions
and learned they had too many deficiencies to be adopted. That study
helped me realizing what would be the important design mistakes to avoid.


> Another thing I had
> done halfway was support for querying objects (without using SQL).
> Basically I had created different types of criteria that could be used, but
> my support for criteria wasn't general enough. IOW, if I didn't forsee that
> you would want a particular type of criteria, then you couldn't use it.
> Propel gets this right by supporting any arbitrary criteria using their
> Criteria object approach (and I'm sure Metastorage has similiar
> functionality). If you can represent it using SQL, you can represent it
> using Propel's Criteria.

Metastorage provides its own OQL (Object Query Language). This means
that you can define functions for your ORM to query objects and
associate a search expression using that OQL. Metastorage compiles that
expression into SQL at code generation time, that may include parameters
to be passed to the function at run time.

This way the code generated by Metastorage does not waste time or memory
building the SQL search clause at runtime, because all query decisions
are antecipated at run time. This results in fast code that is very compact.


> I think it's important to point out, however, that I have learned just as
> much from using Propel as I did from creating my own ORM....I didn't just
> simply drop Propel into place and run with it. First of all, I modified it
> a good bit to work better for my environment. Secondly, as a general rule I
> don't incorporate any third-party code/libraries into my codebase without at
> least doing a cursory review through the code. Since I was particularly
> interested in how this problem was solved, I investigated it more thorougly
> than I normally would.

Right. I feel that I need to clarify that Metastorage approach seems to
be very different from Propel. Metastorage generates self-contained code.

This means that it generates code that does not depend on extra
libraries to perform its function, which is ORM. Of course it uses
Metabase to access the database but Metabase does not implement the base
ORM functionality. Other than that, Metastorage generated code does not
depend on anything else.


> Now, with all that said, it's possible that Chris isn't to the point where
> he would benefit much from plugging in another ORM...in order to learn from
> someone else code you at least have to have a basic understanding of the
> problem they are trying to solve, or it will all be greek to you. And if
> that's the case then you're right, it might hurt more than it will help. So
> let me amend my recommendation by saying "check out Propel/Metastorage if
> you're willing to actually study the approach it takes as opposed to simply
> plugging it in". :)

Right, regardless of what Chris decide, my suggestion was not to use
Metastorage but rather take a look first to what generates. Metastorage
generated code even comes with comments so it easier to understand what
it does and why.


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

[Back to original message]