What Should An ORM Offer?

Posted by Stuart Herbert on May 8th, 2008 in Toolbox.

I have a question for you: what features do you think a good PHP-centric ORM should offer?

16 Comments

  1. Nick Murphy says:
    May 8th, 2008 at 6:05 pm

    The ability to develop one’s domain classes independently from the database schema, *as well as* the data mapping infrastructure. I would love nothing more than a completely transparent mapping layer. SQLAlchemy is the closest thing to this around anywhere… I would think PHP could achieve something similar, though it wouldn’t be sensible to compile the mappers at runtime as with Python.

  2. David says:
    May 8th, 2008 at 6:50 pm

    Have a look at JPA. It should provide the posibilities to model your data on a meta level. To list a few things:

    Model relationships like in an ER diagram (1-1, 1-N N-N), lazy loading and cascade (delete, update, save)

  3. Edward Finkler says:
    May 8th, 2008 at 9:25 pm

    Off the top of my head, a couple key things:

    – it should be able to create ORM classes from existing data structures
    – it should avoid verbosity as much as possible. I would prefer to edit config files that raw PHP code.

  4. Edward Finkler says:
    May 8th, 2008 at 9:25 pm

    Off the top of my head, a couple key things:

    – it should be able to create ORM classes from existing data structures
    – it should avoid verbosity as much as possible. I would prefer to edit config files that raw PHP code.

  5. Edward Finkler says:
    May 8th, 2008 at 9:25 pm

    Off the top of my head, a couple key things:

    – it should be able to create ORM classes from existing data structures
    – it should avoid verbosity as much as possible. I would prefer to edit config files that raw PHP code.

  6. Steve says:
    May 9th, 2008 at 12:31 am

    It should be exactly what it says on the tin, a mapper. A method of automating the data mapper pattern. Far too many so called ORMs implement Active Record, requiring you to use these as domain objects or create your own mapping interface, thus defeating the object. I’d say this largely encompasses the views commented above.

  7. Michael Gauthier says:
    May 9th, 2008 at 1:01 am

    My wish list:
    – Object-Oriented PHP5
    – Uses an iterator interface object that is separate from the recordset itself ala Java collections.
    – Support non-numeric primary keys
    – Support multi-column primary keys
    – Support many-to-many relationships
    – serializable objects

  8. Edward says:
    May 9th, 2008 at 8:56 am

    Have a look at Qcodo. Although this is a framework, the ORM is separate and can be used independently of the view component.

    It’s the best PHP ORM I’ve found. Features include:
    – Solid PHP5 OO code
    – Lightweight
    – Easy to extend
    – Code generation for all data classes
    – Understands foreign key relationships
    – Supports many-to-many relationships

  9. gasper_k says:
    May 9th, 2008 at 9:25 am

    What I miss most with Propel, is some sort of an Identity Map. Two subsequent calls to ObjectPeer::retrieveByPk(1) actually return a different object, which can become very bothersome with larger object graphs.

  10. DG says:
    May 9th, 2008 at 12:52 pm

    Doesn’t Propel (http://propel.phpdb.org) already do most (if not all) of the things people are asking for?

  11. gasper_k says:
    May 13th, 2008 at 8:34 am

    DG: no. 🙂

  12. Larry Garfield says:
    May 17th, 2008 at 3:54 pm

    – No code generation. Code generation means repeating yourself, but being lazy and making the computer repeat yourself for you. That’s still repeating yourself.

    – Multi-entity operations. I want to be able to write “make all books written by author with name ‘Bob’ have the publisher named ‘Addison-Wesley'”, and have it not generate N queries. In straight SQL, I can do that in a single query with a subselect. With an ORM, some extra overhead is acceptable but it should not be more than 4 queries. (Find author Bob, find all his books, find publisher, set publisher.)

    – Don’t do string parsing. String parsing is nasty, error prone, and difficult to debug. If I wanted to write a custom language that gets parsed back into a data structure, I’d write SQL.

    – Transparent. I should always be able to bypass the ORM and hit the SQL directly to run any query I want. That means the underlying tables should be properly normalized, not a bunch of serialized PHP data structures.

  13. Alvaro Carrasco says:
    May 24th, 2008 at 12:47 am

    – Transparent. No ‘extends ActiveRecord’, or ‘extends Persistent’, or ::save() methods on my entities.

    – Entities that look good when you ‘print_r’ them. When I print_r or var_dump an entity it should only show what I expect there: the entity properties. No database configuration, mappings, connection objects, or collections cache.

    – Public properties for table fields. No need to create getters and setters for each field in PHP (just my preference).

    – Easy to use straight sql when needed.

    Since I couldn’t find one that met my needs (I’ve mostly used propel in the past), I wrote my own: http://outlet.knowledgehead.com (It’s open source) I wouldn’t recommend it for a production project yet (still version 0.1) but it’s working great for me so far and I would love to get some feedback.

  14. pimpinken says:
    August 11th, 2008 at 1:22 am

    I think doctrine offers the best and most complete implementation of an orm in php. It is still new but is a great start and things move very fast. I would check it out.

  15. John Kleijn says:
    November 26th, 2008 at 10:50 am

    @steve

    Exactly! I used to create Domain Objects and Data Mappers manually, and while it was a lot more work to create the Data Mappers, I definitely miss the flexibility since I have moved to Doctrine.

    What we need is something that has the flexibility of Data Mapper, with the ease of using an ORM.

  16. Seelaz says:
    October 23rd, 2009 at 3:57 am

    Im currently working in a orm implementation that is in short: “annotated beans, like in hibernate with annotated classes for metadata”. Supporting the common reationships between objects, inheritance mapping strategies, lazy fetching and you dont need to extend a single object from the framework, but instead of an array i use an object called collection that behaves like the java arraylist. Its docummented in brazillian portuguese ,since im brazillian, but i wanted to know if such solution has acceptance by the developers. its gpl and i would be happy to feed more details if you want. Mail me at seelaz@gmail.com for further details. Thanks.

This Month

May 2008
M T W T F S S
« Apr   Jun »
 1234
567891011
12131415161718
19202122232425
262728293031