Re: google SoC - dbobj

I agree that the optimal solution would be a base ORM solution that all others can build off of and use. Just like PDO, it doesn't have to be an end all solution. Just implement the major features that all ORM projects have. The mailing list is great to pick at the brains that have been building such solutions for years. Coming to a solution for a common API would be better in C as a PHP extension. It would also be easy to check for the existence of the extension to use it. Jacob Santos

Hello! This paper seems to be interesting, but I don't have the time to read it now. If only there were such nice documentations when I started this! On the performace point, I can't say anything well-grounded since I have no benchmark results. I'll do some when I have a little more time, then we'll see. The other thing you mentioned ... the bundled ORM tool. I think it would be good to have a "standard sollution" over the current diversity. An analogy came to my mind ... session handling and object persistence. Of course session handling is a much simpler task, I think they share some common points. Like both can be implemented in a number of ways. For session handling now there's a standard implementation that works good for allmost all cases. I don't say, that a similar thing can be achieved for ORM, nor do I say that there should be one ORM implementation that everyone must use. However I think that currently the ORM palette is too diverged (like if everyone would use their own session implementation). There would be good, if there were some "standard" thing, that fit's most people's needs. The bad thing is AFAIK that ORM is interpreted in many ways by PHP developers, so there can't be a one-fits-all solution. For example there are the structured programmer, who don't want to here about objects and classes, but want a nicer interface to access their data in their database. Taking these people into account when building an ORM is very important if we want to keep PHP an easy to learn language. Than there are the people who do everything object oriented, want some of their objects to be persistent, and (for some reason) want them to be stored in a relational database. And there a lot of people in between, who would use an ORM solution mixed with a lot of SQL. I only mentioned three use cases, but in reality, I'm sure that the image is much more complex. However I believe that a "common divisor" could be found, something common in all these cases, that can be made into some form of standard. This shouldn't have many features, but should be extensible. I think if the different more developer-friendly solutions were built on "common divisor", it would result in better high level features, a nicer learning curve (don't have to start from 0 when you need to learn a new ORM implementation) and so on and so on. What I'm really talking about, in the OO aspect, is a base class that provides only some very basic (but very important) ORM features. It should be small, quick and extensible. It should also have a really good, intuitive interface. What you think?