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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
