2008. 02. 8, péntek keltezéssel 11.38-kor Manuel Lemos ezt írta:
> Hello,
>
> on 02/08/2008 06:15 AM Zoltán Németh said the following:
> >> Another aspect is that Metastorage features what is called report
> >> classes. These are classes that perform queries that you define and
> >> generates SQL and PHP at compile time to retrieve data from the
> >> persistent objects for read-only purposes.
> >
> > and what if you want to switch sql server from mysql to oracle or
> > whatever? in propel, you change 1 line in the config, you don't have to
> > regenerate or rewrite anything.
> >
> > the base classes are useful too because if you change your schema, you
> > simply regenerate them and all your extensions remain the same in the
> > child classes.
>
> Metastorage generates totaly database independent code . You don't need
> to regenerate the code to support multiple databases nor have fat base
> classes to access your database or do any other ORM operations.
>
> Currently it generates code that uses Metabase database abstraction
> layer, although it can support other database abstraction layers. It
> supports many databases like MySQL, PostgreSQL, Oracle, Microsoft SQL
> server, SQLite, etc..
ok, so there is not much difference in that :)
>
> Metabase also generates a separate class for installing or upgrading
> your database schema. If you change the definition of you objects, you
> just need to call that class to install, upgrade, downgrade your
> database schemas, safely without loosing any data that was already in
> the database.
>
> This is something very secure, as it does not do any schema changes if
> the underlying database does not support certain things you want to
> change. If you ask for a change that is not possible, it simply fails
> without changing anything. It is not that error prone migrations method
> of Ruby on Rails, that you have to write "SQL" manually to do your
> migrations, and if you made a mistake, your database data is lost.
>
>
schema versioning is cool, AFAIK it is missing from propel but of course
it can transform your schema without data loss.
>
> >> For instance, if you want to send a newsletter to a million subscribers
> >> and you just need the e-mail address and names of the subscribers, you
> >> can tell Metastorage to generate a report class that queries the users
> >> objects and retrives just the name and e-mail address. The report
> >> classes return arrays just like plain SELECT queries.
> >>
> >> If you use the Propel approach you would need to retrieve 1 million
> >> objects of the users class just to pick the name and e-mail address,
> >> which is totally inefficient in terms of memory and very slow.
> >
> > not at all. you can build the criteria for the select and then run a
> > doSelectRS method which gives you only the result set in an array, no
> > objects involved.
>
> That is not exactly what I am talking about. Metastorage has an Object
> Query Language (OQL) that lets you express whatever query conditions you
> want. It generates PHP code with the necessary SQL queries you need. You
> do not have to build any queries programatically at run-time.
in propel you do not touch SQL too ;)
you initialize an object of class Criteria and define whatever you want.
e.g.
$c = new Criteria();
$c->add('whatevercolumn', 'whatevervalue');
of course it can do much more, joins and everything you may need
>
> The generated code can return full SQL statements if you want to execute
> them separately by some other application code, but usually I just use
> the generated report classes directly, as they take care of many things
> like pagination, so I do not have to deal with SQL directly. That is one
> of the great benefits of ORM.
>
> With Metastorage I just do not have to deal with SQL manually nor I am
> forced to retrieve all as objects, not even when I am retrieving just a
> few variables of multiple classes. I do not have to SQL joins manually.
> That would be walking backwards in productivity.
>
>
> >> There are more differences between Metastorage and Propel (and probably
> >> others approach). I just wanted to make the point that the fact that
> >> approaches use generated code, it does not mean that all provide the
> >> same efficiency.
> >
> > yeah, sure. however there is a payoff between efficiency and portability
> > and maintainability, and of course not all these orms have the same
> > level of these. choose the one that fits your needs best.
>
> Exactly. I choose to develop my own because nothing that existed in PHP
> matched my needs and code quality code requirements. Of course doing it
> yourself is an expensive measure because it takes time and skill to
> reach a mature solution. I have been developing Metastorage for 6 years.
> It is very mature and reliable, but there is always room for improvement.
I too had thought about implementing my own ORM, because none of them
fits my needs exactly, however I don't have the time for that... so I
use whatever I find the best at the moment.
greets
Zoltán Németh
>
>
> >> If you are interested about more differences in the approaches, you may
> >> check the Metastorage documentaion:
> >>
> >> http://www.metastorage.net/
> >>
> >
> > sure, I'll check it out when I have some free time
>
>
>
> --
>
> Regards,
> Manuel Lemos
>
> PHP professionals looking for PHP jobs
> http://www.phpclasses.org/professionals/
>
> PHP Classes - Free ready to use OOP components written in PHP
> http://www.phpclasses.org/
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
