Hello, on 02/07/2008 01:52 PM Nathan Nobbe said the following: >> 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. My point is that the base classes are not needed and only lead to less efficient code. They carry all sorts of functionality that you may ever need in all possible persistent classes, but in reality each individual class only needs a fraction of the functionality. > 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. You need to check the actual generated code before you can reach your conclusions. What happens is Metastorage anticipates many decisions to the compile time. It makes static optimizations based on things that will not change at run time. For instance, the list of class variables mapped to database table fields does not change at run time until you do not upgrade your model. Therefore, Metastorage generates SQL queries at compile time that include static lists of fields or query condition clauses. There is no need to waste time recomputing the list of fields or rebuilding query conditions at run-time. This is just an example of static compile time code generation optiomizations. It makes many others based on the knowlegde of things that won't change at run-time. >> The generated code >> does the necessary database calls directly to store and retrieve objects. > > > So does propel. That is not what I understood from last time I talked with Hans. I have yet to see an working example but Propel does not seem to come with one. Also the installation of Propel and all dependent tools is a bit complicated and discouraging for me to try and see what you are talking about. >> 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. No, that is not what I mean. Of course Metastorage generated code needs to concatenate parts of SQL strings, especially when you have values that are only defined at run-time. But for instance, if you need to query an object with a given condition, Metastorage provide an Object Query Language (OQL) that lets you express conditions. Metastorage compiles the conditions and generates PHP string expressions that you just need to concatenate at run time with the rest of the SQL SELECT statement. There is no waste of time and code composing the condition clause at run-time. >> 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. It is not just time, it is also code that you have to write to compose and build queries at run-time before executing. Since SQL queries that you will execute do not change at run-time, Metastorage generates the query clauses at compile time so you do not waste time and additional code to have the queries built by your application before executing. > 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. No, that is not the point. An object of a class may have tens of variables (or properties if you prefer to call them that way). However, to send a newsletter, you just need 2. Why are you going to retrieve all class variables if you just need 2? Another detail, if your newsletter needs values from multiple classes, you need to query objects of the different classes envolved. With Metastorage report classes, I just call a function and get Just Exactly What I Need - JE WIN approach. Not more, not less. It just does what would do if I were not using an ORM tool, a simple select call with eventual joins, conditions, sorting, aggregation, pagination, etc... It would be pointless to use persistent classes for these purposes because you just need to retrieve data for read-only purposes. No objects are updated when you need to generate reports or send newsletters for instance. >> 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. Of course not, you can just retrieve one array at a time. Still, even if you retrieve 1 million arrays to memory with just two elements (name and e-mail), it takes much less memory than retrieving millions of objects with all class variables including all those that you do not need. >> 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. Sorry, you may perform any benchmarks you want, but competition is not my point here. I am just exchanging opinions and points of views. There are ORM tools that are younger and eventually less mature. Their developers may just learn from the benefits that other more mature ORM tools provide. I started Metastorage in 2002 and have analyzed several ORM approaches before I figured what to do that to make an ORM tool that generates satisfactory code as if I would write manually if I had too. Of course, I am not assuming Metastorage provides the best solution in all aspects. There is plenty of room for improvement in Metastorage, so it is also beneficial to demonstrate if other approaches can provide better results than Metastorage approach. -- 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
