SitePoint Sponsor

User Tag List

Page 1 of 5 12345 LastLast
Results 1 to 25 of 121
  1. #1
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why no php O/R Mapping tools to date has seen any major community adoption.

    As the most frequent visitors of this forum can't have missed by now I've spent an awfull lot of time studying already made Object / Relation Mapping tools (ORMs from now on) for php and developing my own. During my litteraly hundreds of hours working on this there's one word that've popped into my mind multiple times: Complexity, namely the complexity most php O/R Mapping tools add and how unnecessary this complexity is in most cases. This is by no means an direct jump on any of the O/R Mapping tools available today, but I have to take some examples(I'm not trying to boost my own solution as it's easly as complex as the ones listed here).

    EZPDO
    • Creates it's own tables, which leades to imensly complex tables, which are very, very, very hard to query with standard SQL.
    • On the subject of tables, the relationship tables are as far from optimized. (excuse the language but: they royally screw normalization on every point.)
    • docBlock tags which are very non-standard.
    • OQL language which is requierd to learn if you don't wanna query the SQL tables.


    Propel
    • Requires you to define your whole base in some non-standardized XML language(tbh: wth were they thinking?)
    • Build step involving Phing, adding even more complexity to the codebase.
    • All finders are generated and static, which makes it very cumbersome to extend them(impossible?) to add new functionallity.
    • Strange method names such as "findJoinAuthors", trying to find one of those methods for your own project requires to check the of the generated file/your xml mappings.
    • Thier Criteria object (new Criterion anyone?) is also strangely complex and feels far from thought thru.


    I've only take the two biggest ones atm, but neither of these have seen any major community adoption, atleast not as far as I can see(I'm aware of that Symfony uses Propel, but check how to "pageinate" something: http://www.symfony-project.com/conte...age/pager.html, that's just silly.). I think the main reason behind this is the complexity they add, a complexity which is unnecessary and just complicates the problem you're trying to solve even more. Then add to the fact that atleast I feel that there are numerous bugs being discovered in both of them and I wouldn't dare to use them for production use. I've yet to see any application complex enough to justify the use and the abstraction that many(all) of the php O/R Mapping tools today add.

    An O/R Mapping tool should be easy to use, it should be fast and abstract the problem you're trying to solve so it's easier for the developer to grasp - none of the current O/R Mapping solutions do this(atleast not in my mind, and I can only speak for myself) and most of them make the problem even harder to grasp after adding thier non-standard vocabulary and syntaxes. Another problem is also that almost none of the problems people apply these O/R M tools make the problem easier to understand - it just makes it harder as many "normal" php application don't have a rich domain model. Why do you people think RoR got such huge adoption and praise, b/c David kept it simple, simple simple and abstracted away problems that developers don't wanna solve.

    Edit(Forgot to add this paragraph in the initial post): An orm should also be easy to integrate with your application, you wanna make html widgets to print out tables, forms, etc? Forget that with any of the current ones.

    I bet most of you won't agree with me, If you do/don't please argue back as this is what we're here for .

    (Excuse my crappy english, it's not my mother tounge)

  2. #2
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Have you looked at Zend Frameworks mapping mechanism yet? Given their ideology of extreme simplicity it will be interesting to see if they can extend this to their object mapping. I understand that it's not finished yet, that some DAO / data mappers might get added in addition to Active Record. It'll be interesting to watch.

    I've looked at Propel very briefly, and felt that the complexity was justified as you get alot of power in return. I do agree that there is a steep learning curve involved too, so much that I haven't had time to explore it properly.

  3. #3
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrike
    Have you looked at Zend Frameworks mapping mechanism yet? Given their ideology of extreme simplicity it will be interesting to see if they can extend this to their object mapping. I understand that it's not finished yet, that some DAO / data mappers might get added in addition to Active Record. It'll be interesting to watch.
    Well, currently thier DAO is not bundled with the release so no, I want to ofcourse

    Quote Originally Posted by Shrike
    I've looked at Propel very briefly, and felt that the complexity was justified as you get alot of power in return. I do agree that there is a steep learning curve involved too, so much that I haven't had time to explore it properly.
    What power do you get in return? I fail to see that, yes you get objects which basicly just wraps your rows 1:1. There's nothing bad in this in itself, but it is overly complex (custom XML, Build step, strange criteria implementation).

    It's not that I don't think O/R Mapping is needed, ofc. it is - but the currently available ones for PHP are, to put it blunt - stupid. You shouold gain an added level of abstraction that's easy to comprehend by using ORMs not get an added layer that complicates things even more.

  4. #4
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From my peek at the documentation I thought the XML configuration was very expressive, allowing foreign key relationships to be defined quite easily. Perhaps other ORMs have a better solution, I've not looked.

    I did think the Criteria code in Propel was somewhat lacking, the ZF syntax of $obj->join()->where()->limit() seems much more appealing.

    I guess a good place to make a comparison is with the de facto Java standard (Hibernate? Spring?) and see where the PHP ones have just got it plain wrong.

  5. #5
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    Well, currently thier DAO is not bundled with the release so no, I want to ofcourse
    Ah yes I've just seen that Active Record is in the docs but not in the source

  6. #6
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrike
    From my peek at the documentation I thought the XML configuration was very expressive, allowing foreign key relationships to be defined quite easily. Perhaps other ORMs have a better solution, I've not looked.
    What if you wanna do database optimizations? Use triggers, foreign key constraints the db? That needs to be added later by "messing" around with the autogenerated db if I'm not wrong. I wouldn't say that it's clear or easy to use. For the easiest of problems which they demonstrate in the manual it looks very very nice, but it doesn't work in practice.

    Quote Originally Posted by Shrike
    I did think the Criteria code in Propel was somewhat lacking, the ZF syntax of $obj->join()->where()->limit() seems much more appealing.
    The ZF syntax doesn't work atm. as it's not released iirc?

    Quote Originally Posted by Shrike
    I guess a good place to make a comparison is with the de facto Java standard (Hibernate? Spring?) and see where the PHP ones have just got it plain wrong.
    Hibernate (Spring isn't even an ORM) adds an immens level of complexity(just look at the amount of books available about Hibernate) - but in the case of java and the problems you use Hibernate for it's actually justified, when you have a realy complex rich domain model you need something like hibernate.

    I guess you could say these about the php ORMs available today:

    • For simple domain models they're to complex and just makes the problem harder to solve.
    • For rich domain models they don't have all the features required and it's not practical to use them.

  7. #7
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    The ZF syntax doesn't work atm. as it's not released iirc?
    Quite possibly, I'm looking at the docs more than the source currently.

    I remember another thread recently which touched on why PHP's O/R tools were the way thay were. You have to concede that some talented people are working on these products...so why aren't they more simple to use? Why hasn't an easy to use product been developed? Maybe the problem area requires a complex solution, simple approaches are too...simple?

  8. #8
    SitePoint Member
    Join Date
    Feb 2006
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The ORM from Rails is very easy to work with. It can't do everything but it is extensible.
    I don't say that a port should be made to Php (I don't like every part of it) but it is probably a good example of a simple and succesfull ORM.

    Hibernate is also a good example of a good and succesfull ORM, but it is way to complex for PHP. But you could look at how some parts work. But a port would be very wrong.

  9. #9
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrike
    I remember another thread recently which touched on why PHP's O/R tools were the way thay were. You have to concede that some talented people are working on these products...so why aren't they more simple to use? Why hasn't an easy to use product been developed? Maybe the problem area requires a complex solution, simple approaches are too...simple?
    I don't doubt the development teams talents at all, but I don't think they've done it right. Look at ActiveRecord in rails, easy and flexible enought to do exactly what it should and not more. I think the php orms are trying to do to much - but they don't get all the way(hibernate). So instead they land in some middle ground that is to complex for simple domains (which is where php is used 95% of the time) and to simple for complex domains, which makes them unusable there.

    Quote Originally Posted by smies
    The ORM from Rails is very easy to work with. It can't do everything but it is extensible.
    That was my example =/.

  10. #10
    SitePoint Member
    Join Date
    Feb 2006
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    That was my example =/.
    Sorry, but I needed to say it again .

  11. #11
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I read that ZF's active record bore a striking resemblance to the RoR one. Maybe that's not a bad thing

  12. #12
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrike
    I think I read that ZF's active record bore a striking resemblance to the RoR one. Maybe that's not a bad thing
    Except that the ZF AR implemention doesn't work because of the "self" + "static" "bug" in php.

  13. #13
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why don't we list what should an ORM solution have (a feature list) and work from there?

    Here's my list, by no means complete:

    * has to use an already defined database, ie. the database must be independently accessible by other applications
    * no hand-written config files (if any are used, they should be automated), XML or any other format
    * usable out of the box, at least for the simple cases (e.g. for single PK tables with up to one FK, which are most common on Web) -- no need to write complex table-classes before using it

    Feel free to add your own suggestions.

  14. #14
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also the fact that alot of PHP applications aren't OO, so database access layers like ADODB get used.
    Thou it's just recently added a AR implementation.. http://phplens.com/phpeverywhere/

  15. #15
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only thing I hate in both ZF's and RoR's AR, which apparently got accepted by the ADOdb's as well, is the convention that class names are singular and table names are plural. My personal convention is to view tables as entities, and thus I keep their names in singular as well. Maybe I'm weird that way, but I'd like that at least to be a modifiable setting.

  16. #16
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrike
    Why hasn't an easy to use product been developed? Maybe the problem area requires a complex solution, simple approaches are too...simple?
    Quite possible. SQL isn't an inferiour language. For solving it's problem domain, it beats any object-model by far. So perhaps the point is that if your model is sufficiently complex, ORM just isn't a good idea. That leaves us with the low-to-moderately complex models. So IMHO ORM's should target the low segment, but play nice so that you are always free to switch over to a more direct SQL approach anytime you see the need for it.

    Quote Originally Posted by Ren
    Also the fact that alot of PHP applications aren't OO, so database access layers like ADODB get used.
    Uhm ... An ORM without objects is kind of ... not possible. SQL fits very well with a procedural paradigm, so in procedural code, I don't think you actually need complex mappings. You'll benefit from connection-abstraction ofcourse to level out the dialectic differences between rdbms's. If I'm not mistaken, that's what adodb does ?

  17. #17
    SitePoint Member
    Join Date
    Feb 2006
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    The only thing I hate in both ZF's and RoR's AR, which apparently got accepted by the ADOdb's as well, is the convention that class names are singular and table names are plural. My personal convention is to view tables as entities, and thus I keep their names in singular as well. Maybe I'm weird that way, but I'd like that at least to be a modifiable setting.
    The thing is that I learned at school (Higher Computer Sciences) that table names should always be singular. So I also find it strange that some DB layers rather have it Plural.

  18. #18
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Why don't we list what should an ORM solution have (a feature list) and work from there?
    We did that before.

  19. #19
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Uhm ... An ORM without objects is kind of ... not possible. SQL fits very well with a procedural paradigm, so in procedural code, I don't think you actually need complex mappings. You'll benefit from connection-abstraction ofcourse to level out the dialectic differences between rdbms's. If I'm not mistaken, that's what adodb does ?
    That was my point. PHP ORMs adoption isn't high as alot of PHP code written is procedural.

  20. #20
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    That was my point. PHP ORMs adoption isn't high as alot of PHP code written is procedural.
    Ah. I agree with you then.

  21. #21
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by michel
    Well, from skimming through that thread, it seems that there most of the time people suggested what solutions to be included into the ORM tool, not what problems it should solve.

  22. #22
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's a grandiose but loose architectural sketch based on various ideas from today. I was thinking, what if the structural mappings could be added as separate components on top of a (what was that you called it, Marcus?) basic data-centric object layer, in a similar way to what I did with the embedded value.

    You could have it as simple or complex as you want by adding or removing components in the upper layer. Or just using the lower one.

    Then there is the part that has to do with constructing the requests to the lower layer so they're faster and uglier. My intuition tells me that part could possibly be managed by a separate component, keeping the rest of the design simpler. I've called that an Optimizer.

    Don't take the details (such as the dependency arrows to and from the Optimizer) too seriously. As I said, it's really a loose idea.
    Attached Images Attached Images
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  23. #23
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    That was my point. PHP ORMs adoption isn't high as alot of PHP code written is procedural.
    Ah, then I also understand your point - I was a bit confused iirc(finally I can use it and know what it means *yay*).

    I'm realy trying to piece out what an O/R Mapping tool should have in php - as I feel the current ones are way to complex(as you might've noticed.. god I used that word much in my initial post.. hehe). I'll probably post som ideas in the "Feedback on OR mapping unit tests thread", as I don't wanna clutter this thread with my own ideas, etc.

  24. #24
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As a very satisfied user of Propel I feel compelled to provide a different viewpoint on this topic.
    Quote Originally Posted by thr
    Propel
    • Requires you to define your whole base in some non-standardized XML language(tbh: wth were they thinking?)
    I'm not sure I understand your point here. What exactly do you mean when you say "non-standardized XML" or "custom XML"? The very idea of that seems to me to be an oxymoron. The XML file you use to describe your database schema and mapping strategy is a well-formed XML document that complies with a defined DTD. Doesn't this make it "standardized"? (And while I'm at it, isn't all XML "custom XML"? After all, it's eXtensible Markup Langauge, is it not?) Can you give an example of XML that isn't "non-standardized" or "custom"? Maybe I'm missing the proper context to understand your point.

    Secondly, I don't see what the problem is with defining mappings in XML. Once you have taken the approach of supporting arbitrary mappings between fields and attributes then those mappings have to be defined somewhere. Personally speaking I don't care for any ORM that autogenerates attributes based on the mere presence of a field. I very much prefer to be explicit. Then again I'm working with legacy databases which are unfortunately (and for reasons beyond my control) filled with cruft and ugliness that I want to abstract away. The separate mapping file approach allows me to store all that ugliness in a single place, for the most part.

    I've been toying with Hibernate in my spare time. As you may be aware, it offers several different mechanisms for describing mappings between Java beans and database tables/columns. There's the separate XML mapping file approach, the XDoclet approach, and finally the Java 5 annotation approach. Before I started toying with it I assumed that I would be using annotations to define my mapping as the general consensus seems to be that it's the approach with the least amount of overhead. However, now that I've actually been using it I've found that I much prefer the separate XML file approach. As I said before, I want that mapping information to be separate and contained in one location, not inferred automatically or spread throughout various class files. I've found that I'm usually either concerned with my business/domain logic, or I'm concerned with the way my actual mapping is being done, but usually not at the same time. For that reason I like that the mapping is kept separate from the actual code. All IMHO, of course.

    • Build step involving Phing, adding even more complexity to the codebase.
    One of the design decisions of Propel (and the Java ORM it is based on, Torque) is the idea of pre-generating base classes for your persistable objects. In the case of PHP, I think it's a very valid approach. It's not really feasible (IMHO) to take a Rails-like ActiveRecord approach in PHP where classes/methods are generated on the fly from database introspection. First of all, PHP doesn't offer the same metaprogramming facilities that Ruby does, so you can't, for example, add a method to an already-defined class at runtime. Sure, you could generate a string that defines a class and then eval() it, but that brings us to the second problem with this approach in PHP: the fact that all code is parsed and compiled on every request. With that in mind, runtime introspection is just too expensive to be feasible. (My understanding of Rails is even though it is shared-nothing like PHP in as much as it does not store state information in memory, it also has similarities with an application-server approach in as much as the ruby processes are persistent once they have been created, so the startup/compilation overhead is incurred only once for each forked process. If my understanding is wrong, please let me know; I have no direct experience with Rails.)

    Anyway, once you have taken the approach of pre-generating classes then some sort of build process is necessary, hence Phing. I don't find it particularly complex, other than the fact that it is a dependency that has to be installed. Sure, the build scripts could have been implemented as pure-PHP cli scripts, but I can definitely understand why the Propel devs chose the Phing approach, as it is much more general and flexible for handling arbitrary tasks related to building/deploying code. It's the same reason that most build systems in Java use something like Ant or Maven as opposed to a pure Java program.

    • All finders are generated and static, which makes it very cumbersome to extend them(impossible?) to add new functionallity.
    The static classes approach I am not fond of, but they are by no means impossible to add functionality to. Cumbersome, perhaps, but not impossible. I've added lots of functionality to the finder classes in my Propel projects.
    • Strange method names such as "findJoinAuthors", trying to find one of those methods for your own project requires to check the of the generated file/your xml mappings.
    Those are convenience methods, and I actually find that I either don't use them or I create my own custom methods in those cases where I want to do eager fetching of related data.

    However, I've found that in any project complex enough to warrant using an ORM (and for me, just about ANY PHP project) it is extremely helpful to use a documentation system such as Doxygen or PHPDocumentor (although I prefer the former) that automatically generates API documentation from your code. Whether the method names are strange or not, I find that I often cannot remember them easily especially when I'm dealing with a large number of classes. I have several applications that depend on a set of more than 40 Propel-provided classes, and API documentation is pretty essential for me.

    • Thier Criteria object (new Criterion anyone?) is also strangely complex and feels far from thought thru.
    We've already discussed this point in another thread, but as I pointed out there, there are advantages that the Criteria approach provides. However, I do concede that it is not intuitive and definitely has a learning curve. Ideally Propel would follow in Hibernate's footsteps and offer both a Criteria object approach AND an OQL mechanism, but oh well...

    I've only take the two biggest ones atm, but neither of these have seen any major community adoption...I think the main reason behind this is the complexity they add, a complexity which is unnecessary and just complicates the problem you're trying to solve even more.
    I have my own thoughts on why the PHP community hasn't adopted these ORMs (or ORMs in general), more on this in a minute. However, I disagree that Propel in particular always makes projects more complicated. In my case, it greatly simplified the problem I was trying to solve. In my project it was necessary to deal with a large number of related database tables. I prefer to use an OO approach to dealing with this information as I cannot abide having the cumbersome and error prone code that deals with marshalling data to and from the SQL database interspersed throughout my code base. And if I'm going to take an OO approach then I'm either creating my own homegrown ORM or I'm using one that's already available. In my case it was much simpler to integrate Propel into my project (with some tweaks, more on that in a moment) that it was to get my own homegrown ORM up to the point where it could match Propel in the features department.

    Then add to the fact that atleast I feel that there are numerous bugs being discovered in both of them and I wouldn't dare to use them for production use.
    There are bugs in Propel, unfortunately, but no more than what I've found in the average open source PHP project. Part of it is that it isn't widely used, as you've pointed out, so there have been fewer eyes looking at the code and fewer edge cases encountered. It's pretty much a forgone conclusion to me that any PHP codebase that I'm going to use is probably going to have bugs that I'm going to have to fix in order to do so. The question then becomes how many of them are there and how hard is it to fix them? If the architecture is nice (which I think it is in Propel) then I just import the code as a vendor branch in my local Subversion repository and start using it, fixing the (hopefully minor) bugs as I go along. This approach is definitely not for everyone, but I still don't feel that Propel is behind the curve bug-wise, and it is most definitely solid enough for production use, as my experience testifies.

    I've yet to see any application complex enough to justify the use and the abstraction that many(all) of the php O/R Mapping tools today add.
    With all due respect, just because you haven't seen the applications this complex doesn't mean they don't exist. They may not be as common in the PHP community as they are in other communities (more on that in a minute) but they are out there.

    Why do you people think RoR got such huge adoption and praise, b/c David kept it simple, simple simple and abstracted away problems that developers don't wanna solve.
    The problem with your theory is that Hibernate is hugely popular in the Java space, and is arguably just as complex as Propel. To me the difference is not in any major blunders in the design of Propel (or the other available ORMs), but in the differences between the Java and PHP communities (more in a minute). Also, although RoR is very nice (by all accounts) don't discount the effect of good marketing. DHH and the various other RoR advocates are very good spokespeople for their product, and the hype they have produced has definitely helped to keep Rails in the spotlight and has spurred increased adoption. Not everyone has the skill, the time, or the connections to market their projects in a similar way.

    Now, as for my opinion on why these ORMs haven't been adopted, I think there are two major reasons, which are somewhat related to each other.

    The first is that the average PHP application isn't complex enough to warrant an ORM as flexible as something like Propel. This isn't a slam against PHP, but it seems to me that people who are solving more complex problems or dealing with a complicated data model are more likely to be using a platform other than PHP to do so. I do not want to turn this thread into a language war, but I definitely think that each platform has its own "sweet spot" in the problem space where it's particularly suited. For example, I find PHP's lack of namespace support to be a huge drawback when taking an ORM approach. It's inevitable that many projects using an ORM approach to access persistent data is going to have more classes than the average PHP project. It's often convenient to refer to these classes by very simple names, such as User, Preference, etc. but this is an unwise approach to take in PHP, which doesn't offer a way to encapsulate groups of names in order to avoid collisions. Sure, having namespaces adds overhead to the language (nothing comes for free) but they're indispensible for certain types of problems. Not everyone needs them, but I feel that people who are considering using an ORM approach probably do, and these people are less likely to be using PHP, and more likely to be using something like .NET or Java, for that and other reasons. Again, I'm not saying Java or .NET are better than PHP, but I am saying that there are certain classes of problems (which may not necessarily be the most common type) where the complexity and overhead of Java and .NET are a small price to pay for the increased power and flexibility they provide in that problem domain.

    The second issue is that the vast majority of the PHP userbase do not have a strong CS background, and concepts such as object relational mapping are difficult for them to fully grasp. Once again, this is not a slam on PHP or the PHP community, and I should say that it does not apply to anyone reading this forum, as you are less likely to be an amateur programmer by virtue of the fact that you're even participating here. However, I feel that we in this group represent a very small minority of the total PHP user base. The prevailing culture just isn't very compatible with the idea of something like Hibernate or Propel, IMHO. This point has already been made, but lots of PHP programmers are procedural programmers who came into PHP because it is very simple. Consider your complaint about Phing... the average PHP programmer probably would find Phing too complex, but consider its analog in the Java community, Ant. Ant is very ubiquitous in the Java space and no one there would bat an eye at a project's dependency on Ant. Java people are just more used to that level of complexity. Whether this is because they are typically dealing with more complex problems, or because Java itself is complex and they are already used to it is up for debate, I suppose.

    It's not that I don't think O/R Mapping is needed, ofc. it is - but the currently available ones for PHP are, to put it blunt - stupid.
    Perhaps this falls under your "crappy english" disclaimer, but just so you know, in English a statement such as that is considered to be fairly disrespectful. The existing ORMs in PHP may not be to your taste, but that hardly makes them "stupid". Such a statement trivializes the very real hard work that multiple people have put into these projects, and I feel that you have not demonstrated why these projects deserve such a label. Just my opinion.

  25. #25
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    I'm not sure I understand your point here. What exactly do you mean when you say "non-standardized XML" or "custom XML"? The very idea of that seems to me to be an oxymoron. The XML file you use to describe your database schema and mapping strategy is a well-formed XML document that complies with a defined DTD. Doesn't this make it "standardized"? (And while I'm at it, isn't all XML "custom XML"? After all, it's eXtensible Markup Langauge, is it not?) Can you give an example of XML that isn't "non-standardized" or "custom"? Maybe I'm missing the proper context to understand your point.
    Ok, maybee the wording non-standardized XML was wrong - my point was that it's something the developer has to learn, yet another layer of code to maintain and keep up to date, learn to use(as it's XML and you have to learn the exact DTD this particular approach offers you).

    Quote Originally Posted by DerelictMan
    Secondly, I don't see what the problem is with defining mappings in XML. Once you have taken the approach of supporting arbitrary mappings between fields and attributes then those mappings have to be defined somewhere. Personally speaking I don't care for any ORM that autogenerates attributes based on the mere presence of a field. I very much prefer to be explicit. Then again I'm working with legacy databases which are unfortunately (and for reasons beyond my control) filled with cruft and ugliness that I want to abstract away. The separate mapping file approach allows me to store all that ugliness in a single place, for the most part.
    Well, as I said in my above paragraph doing it in XML adds YAL (Yet Another Layer) that needs to be maintianed, learned, etc.

    Quote Originally Posted by DerelictMan
    I've been toying with Hibernate in my spare time. As you may be aware, it offers several different mechanisms for describing mappings between Java beans and database tables/columns. There's the separate XML mapping file approach, the XDoclet approach, and finally the Java 5 annotation approach. Before I started toying with it I assumed that I would be using annotations to define my mapping as the general consensus seems to be that it's the approach with the least amount of overhead. However, now that I've actually been using it I've found that I much prefer the separate XML file approach. As I said before, I want that mapping information to be separate and contained in one location, not inferred automatically or spread throughout various class files. I've found that I'm usually either concerned with my business/domain logic, or I'm concerned with the way my actual mapping is being done, but usually not at the same time. For that reason I like that the mapping is kept separate from the actual code. All IMHO, of course.
    That statement is your preference, as my initial post was my thoughts, etc. But in java I can see why they support the XML/docBlock/Annotation, as atleast the XML version allows redeploying of an application without recompile, etc. There's no reason to do this in php as it's an dynamicly typed language.

    Quote Originally Posted by DerelictMan
    One of the design decisions of Propel (and the Java ORM it is based on, Torque) is the idea of pre-generating base classes for your persistable objects. In the case of PHP, I think it's a very valid approach. It's not really feasible (IMHO) to take a Rails-like ActiveRecord approach in PHP where classes/methods are generated on the fly from database introspection. First of all, PHP doesn't offer the same metaprogramming facilities that Ruby does, so you can't, for example, add a method to an already-defined class at runtime. Sure, you could generate a string that defines a class and then eval() it, but that brings us to the second problem with this approach in PHP: the fact that all code is parsed and compiled on every request. With that in mind, runtime introspection is just too expensive to be feasible.
    I'd say that it's about as counter intuitive as possible to add a build step to a dynamic language, that's basicly taking away one of the biggest (if not the biggest) advantage dynamicly typed languages have over languages such as Java. I'm well aware that php doesn't offer the same metaprogramming as Ruby does - I never said that the perfect orm is a ActiveRecord::Base clone. Runtime introspection can be cached with ease so that's realy no problem.

    Quote Originally Posted by DerelictMan
    Anyway, once you have taken the approach of pre-generating classes then some sort of build process is necessary, hence Phing. I don't find it particularly complex, other than the fact that it is a dependency that has to be installed. Sure, the build scripts could have been implemented as pure-PHP cli scripts, but I can definitely understand why the Propel devs chose the Phing approach, as it is much more general and flexible for handling arbitrary tasks related to building/deploying code. It's the same reason that most build systems in Java use something like Ant or Maven as opposed to a pure Java program.
    Well phing is quite complex, no it's not a magic black box that says "Phing" on and that none except the author(s) understand - but it's still a part of adding even more complexity ontop of what mostly is a relatively simple problem(Yes I'm aware there are "complex" php applications, but they're rare and far between).


    Quote Originally Posted by DerelictMan
    The static classes approach I am not fond of, but they are by no means impossible to add functionality to. Cumbersome, perhaps, but not impossible. I've added lots of functionality to the finder classes in my Propel projects.
    Those are convenience methods, and I actually find that I either don't use them or I create my own custom methods in those cases where I want to do eager fetching of related data.
    Well, for once you have to rewrite all "self::" calls to "ClassName::" if I'm not totaly wrong? Yes I'm aware that they're convenience methods but it's still something that could've been built into propel itself - either by an advanced QBE engine or OQL.

    Quote Originally Posted by DerelictMan
    However, I've found that in any project complex enough to warrant using an ORM (and for me, just about ANY PHP project) it is extremely helpful to use a documentation system such as Doxygen or PHPDocumentor (although I prefer the former) that automatically generates API documentation from your code. Whether the method names are strange or not, I find that I often cannot remember them easily especially when I'm dealing with a large number of classes. I have several applications that depend on a set of more than 40 Propel-provided classes, and API documentation is pretty essential for me.
    Agree, and it makes your the above point (the specialized finder methods) a little more workable.

    Quote Originally Posted by DerelictMan
    We've already discussed this point in another thread, but as I pointed out there, there are advantages that the Criteria approach provides. However, I do concede that it is not intuitive and definitely has a learning curve. Ideally Propel would follow in Hibernate's footsteps and offer both a Criteria object approach AND an OQL mechanism, but oh well...
    Atleast I find the criteria object in propel illogic and very "uneasy" to work with as the naming is far from clear.


    Quote Originally Posted by DerelictMan
    I have my own thoughts on why the PHP community hasn't adopted these ORMs (or ORMs in general), more on this in a minute. However, I disagree that Propel in particular always makes projects more complicated. In my case, it greatly simplified the problem I was trying to solve. In my project it was necessary to deal with a large number of related database tables. I prefer to use an OO approach to dealing with this information as I cannot abide having the cumbersome and error prone code that deals with marshalling data to and from the SQL database interspersed throughout my code base. And if I'm going to take an OO approach then I'm either creating my own homegrown ORM or I'm using one that's already available. In my case it was much simpler to integrate Propel into my project (with some tweaks, more on that in a moment) that it was to get my own homegrown ORM up to the point where it could match Propel in the features department.
    Good for you then, but I feel that propel takes to much and gives to little. The whole build-step-xml-mapping is perfect for java or other environments where you don't have dynamic typing, but here we do and there is no excuse in the world that can justify to take that away imho.

    Quote Originally Posted by DerelictMan
    There are bugs in Propel, unfortunately, but no more than what I've found in the average open source PHP project.
    Probably true there, but an ORM with bugs is much much much more serious then your avarage forum software - as other applications depend on the ORM to do it's job 100% correct.

    Quote Originally Posted by DerelictMan
    If the architecture is nice (which I think it is in Propel)
    It's static abuse, this is far from "nice architecture", atleast in my book.

    Quote Originally Posted by DerelictMan
    With all due respect, just because you haven't seen the applications this complex doesn't mean they don't exist. They may not be as common in the PHP community as they are in other communities (more on that in a minute) but they are out there.
    I know they exists, but I think you agree on the fact that 95% of the php projects that use EZPDO/Propel just complicates thier problem further because they want to use a fancy solution on a simple problem, which is - yes - stupid.

    Quote Originally Posted by DerelictMan
    The problem with your theory is that Hibernate is hugely popular in the Java space, and is arguably just as complex as Propel. To me the difference is not in any major blunders in the design of Propel (or the other available ORMs), but in the differences between the Java and PHP communities (more in a minute). Also, although RoR is very nice (by all accounts) don't discount the effect of good marketing. DHH and the various other RoR advocates are very good spokespeople for their product, and the hype they have produced has definitely helped to keep Rails in the spotlight and has spurred increased adoption. Not everyone has the skill, the time, or the connections to market their projects in a similar way.
    I agree that it's not only the design blunders of propel(or the others) that are the problem, (not going to bash the build step again) but many things could've been done much much better.


    Quote Originally Posted by DerelictMan
    The first is that the average PHP application isn't complex enough to warrant an ORM as flexible as something like Propel.
    I'd say that 99.9% of the applications developed in php don't warrant any of the current ORMs available for php as they're overly complex.


    Quote Originally Posted by DerelictMan
    Perhaps this falls under your "crappy english" disclaimer, but just so you know, in English a statement such as that is considered to be fairly disrespectful. The existing ORMs in PHP may not be to your taste, but that hardly makes them "stupid". Such a statement trivializes the very real hard work that multiple people have put into these projects, and I feel that you have not demonstrated why these projects deserve such a label. Just my opinion.
    My english ain't that crappy, I know perfectly well how insulting it is to say that something is "stupid", but to take the two biggest flaws of Propel and EZPDO:

    Propel: Build step in a dynamic environment, yes I'd say this is stupid.
    EZPDO: Take a look thier relationship mapping and how insanely many queries it takes to do some stuff, I'd say thier whole core/design is stupid.

    You might think it's harsh and trivializes what work they've put into it, but I think some of thier design decisions are realy stupid - so why shouldn't I say so? Again... just my opinions .


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •