On Feb 7, 2008 10:15 AM, Manuel Lemos <mlemos@xxxxxxx> wrote: > What happens is that Propel relies on fat base classes that the > generated persistent object classes need to inherit to do the actual > Object-relational mapping. this is so that there is a customizable layer that will not be impacted by subsequent regeneration. qcodo has the same concept and i suspect doctrine does as well. Metastorage generates self-contained code. This means the generated > classes are root classes that do only what you need. Then they must themselves be 'fat'; using inheritance to encapsulate common functionality is obviously a sound technique. > The generated code > does the necessary database calls directly to store and retrieve objects. So does propel. > It does not call base classes like Propel generated classes that waste > time composing SQL queries at run-time. Metastorage generated classes > already have the necessary SQL built-in to execute the queries without > further analysis at run-time. It has *all* the necessay sql embedded in it? i find this hard to believe. say for example i run a query without a limit clause; then i want to run the same query with a limit clause; it is simply impractical to pre-write 2 queries, one with a limit clause and one without it into the code at compile time. moreover i sincerely doubt this is the approach theyve taken because if you just sit and think about it for a second, with even a small number of tables the permutations on the set of all possible queries would be staggering. such classes that would encapsulate said number of permutations would be way beyond 'fat', i would imagine. so im guessing metastorage does some sort of query composition at runtime. > 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. so you save some time building queries at runtime for special cases; thats kind of nice; but i dont think it takes much time to actually build a query anyway. 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. thats great, arrays are a little more lean than objects; but obviously they are not wrapped with any additional functionality; such as the ability to fetch the value of a record in a related table or alter the current value. > 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. well lets just remember that even though arrays are just data and therefore less expensive in terms of memory and quicker to iterate; there would still be 1 million arrays of data. > 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. i would like to see some benchmarks of propel vs. metastorage. i would do them myself except that i simply dont have time to do a proper experiment in the near future. i will certainly consider an analysis of metastorage for a rainy day though. -nathan
