Comments on: What Should An ORM Offer?

By: Seelaz

Seelaz — Fri, 23 Oct 2009 03:57:41 +0000

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.

By: John Kleijn

John Kleijn — Wed, 26 Nov 2008 10:50:06 +0000

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

By: pimpinken

pimpinken — Mon, 11 Aug 2008 01:22:46 +0000

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.

By: Alvaro Carrasco

Alvaro Carrasco — Sat, 24 May 2008 00:47:05 +0000

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

By: Larry Garfield

Larry Garfield — Sat, 17 May 2008 15:54:32 +0000

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

By: gasper_k

gasper_k — Tue, 13 May 2008 08:34:48 +0000

DG: no.

By: DG

DG — Fri, 09 May 2008 12:52:13 +0000

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

By: gasper_k

gasper_k — Fri, 09 May 2008 09:25:03 +0000

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.

By: Edward

Edward — Fri, 09 May 2008 08:56:35 +0000

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

By: Michael Gauthier

Michael Gauthier — Fri, 09 May 2008 01:01:12 +0000

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