SitePoint Sponsor

User Tag List

Page 1 of 5 12345 LastLast
Results 1 to 25 of 121

Hybrid View

  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)
    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

  5. #5
    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.

  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 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.

  15. #15
    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.

  16. #16
    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

  17. #17
    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 BerislavLopac
    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.
    Actually, I think that in this case the form is much more important than the problem. In the case of ORM, the problem is all about form - You already have access to the data-layer, but what the ORM provides is a different interface to the same thing.

    More generaly speaking, I'll say that as a programmer, the api of a library is often equaly or more important as it's inner workings, since the api implies how I would have to work with it.

  18. #18
    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 kyberfabrikken
    More generaly speaking, I'll say that as a programmer, the api of a library is often equaly or more important as it's inner workings, since the api implies how I would have to work with it.
    (This is turning out more and more as a "bash ezpdo/propel" thread, but ezpdo is sadly my best worst example). I'd say that the API is not as important as the inner workings, the performance can take quite a hit if you don't got your internal stuff right - take ezpdos 1 > * and * <> * relations, they'are lazyloaded one by one, so a fetching a person and looping his posts becomes: 1+N, the most dreaded query-sequence ever which makes performance hit rock bottom.

  19. #19
    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 kyberfabrikken
    Actually, I think that in this case the form is much more important than the problem. In the case of ORM, the problem is all about form - You already have access to the data-layer, but what the ORM provides is a different interface to the same thing.
    In any software project, functional specifications are most important; that is also true of ORM.

    In other words, we must define what we want our tool to do. Take one of my above requirements as an example:

    * has to use an already defined database, ie. the database must be independently accessible by other applications

    It is very important to know whether our database should be accessible from other programs, who don't have the benefit of our ORM. Because if so, we should put more thought into the database design and normalization; if not, we can have a simple and universal database layout, which could be generated automatically and is dedicated to persist the objects in the simplest way (e.g. through simple serialization).

  20. #20
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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
    Interestingly, Propel meets all these criteria. Granted it may not meet your requirements in some other cases, but it fits those.

  21. #21
    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 lftl
    Interestingly, Propel meets all these criteria. Granted it may not meet your requirements in some other cases, but it fits those.
    Hmm, let's se:

    * Has to use an already defined database, ie. the database must be independently accessible by other applications - Check, Propel meets it

    * No hand-written config files (if any are used, they should be automated), XML or any other format - No, propel requires .xml config files.

    * 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 - No, propel requires definition and building of your objects and relations, I'd hardly say that's "out of the box".

  22. #22
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    No hand-written config files (if any are used, they should be automated), XML or any other format - No, propel requires .xml config files.
    I'll say this point is open to a little interpretation. My interpretation is that Propel passes this point because it can reverse engineer its config file from an existing database. So yes, a config file has to be created, but it doesn't have to be by hand.

    Quote Originally Posted by thr
    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 - No, propel requires definition and building of your objects and relations, I'd hardly say that's "out of the box".
    Again, up to interpretation of what is meant by out of the box. If defining the schema and compiling the om is beyond out the box behavior, then Propel doesn't really do anything out of the box. I definitely understand, that's more work than some want to go through to get it up and running, but it's not the definition I was going by when I made my comment.

  23. #23
    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 lftl
    If defining the schema and compiling the om is beyond out the box behavior, then Propel doesn't really do anything out of the box.
    That was exactly my point. Essentially, I want ORM to be able to (at least for simple tables, and given an already created database) do something along these lines:
    PHP Code:
    $table = new ORMTableWhatever('table_name');
    $table->doTheMagic(); 

  24. #24
    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/

  25. #25
    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 ?


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
  •