Stuart Herbert On PHP

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

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

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

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

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

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

   DG: no.

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