• Belongs-To – This is the most basic form of a FK representation in an ORM. A field in a model is designated as type Belongs To when that field has is a FK that references the primary key (PK) in another model (table). I say model since the Belongs To is used to describe the behavior of one model that contains a FK index in relation to another model that is the target of that FK index. The typical default behavior would be for the field to be named by using the target model’s name joined to the target model’s PK field name by an underscore such as author_id. The assumption in this example being that the author table would have a PK field named id.
• Has-One – This is the other side of the Belongs-To convention. This tells the model that another model is using this models PK as the target for its FK. The model can use this relationship to manage cascading deletes, joined selections, etc. The implication is that the model expects there to be one and only one FK in the remote model (table) attached to each record in this model (table).
• Has-Many – This is the same as Has-One except now the model expects there to be one or more FK’s in the remote model (table) attached to each record in this model (table).
• Many-To-Many – Although you might assume this is similar to Has-Many, it is actually more akin to Belongs-To. This convention represents a FK relationship from this model (as with Belongs To) to an intersection table that in turn joins it to another model. The typical implementation contains a Through property that defines the name of the intersection table. By default this table will typically be named by joining the name of each model (table) connected to it with an underscore character.

That is all there is to it. Although this is a simple explanation of these four relationship types, I think you can begin to see how the ORM will rely on each to execute desirable behaviors as you interact with your database through model objects. If you have any comments or corrections to the above please let me know.

I hope this view is helpful to you. I know it helped me to get a better perspective of Jelly and how it was designed.

Update: The official Jelly web site can be found at http://jelly.jonathan-geiger.com/.

As a PHP developer my list of options is currently limited to ORM tools built for PHP. So far I have tried two of these. Although there were a number of things that I liked about each solution, there was at least one aspect of each that I did not like. I decided to cast my net wider and look at other PHP ORM solutions. As I did more research I began to realize there are notable differences among the key products in the space as well as a number of “upstart” competitors that are rising up to fill any perceived gaps. With a number of high profile and niche products to consider I quickly realized that choosing between them would be difficult.

This led to the post you are now reading. I decided that rather than simply compare features of the existing products I should put together a list of what is important to me in an ORM solution. If I can define which features I want (from most to least important) and which features I don’t want then I can use the list to compare against each solution. The one that best matches my list is the one I’ll pursue next. So without further preamble, here is my list. Note that it is my list “today” and it will likely change or evolve as I learn more about ORM solutions.

Things I Want (Must Haves)

• Open Source – I’m not opposed to a commercial solution, but for now I want open source.
• Strong Community – There is strength in numbers.
• Good Documentation – Quick Start Guide, User Guide, Reference Manual, User Contributed Cookbooks, etc.
• Easy to Install – You would be surprised at how many people just assume you can figure it out yourself.
• Easy to Use – I don’t want to struggle with an ORM. The classes and methods should be intuitive.
• Fast – Performance that is within 20% to 25% of hand coded PDO based solution.
• Good Query Builder – The underlying query builder should be easy to use directly and the methods should behave in an obvious and straight forward way.
• Native SQL – The ability to easily use SQL to populate result sets for so called “edge cases.” Pet peeve: Most of the notable work developers do is edge cases. If it were easy, anybody could build it.
• Data Form Marshaling – Why should I have to catch data from a form when the form should be built on an ORM model?
• Built In / Custom Validation – Should have a simple to configure and use validation strategy.

Things I Would Like (Nice to Have)

• Strong Typing – Makes life easier when working with databases.
• Form Decorators – Model awareness of web form decorator class or classes and ability to return a default decorator from a method.
• Integrated Security – Stop XSS, SQL Injection, etc.
• Flexible Architecture – Ability to have inherited model objects or contained model objects.
• Automatic Model Validation at Design Time – It would be helpful if there was a global option to turn on or off model validation. This way a model would check to make sure the underlying table was appropriate at design time, but would not waste cycles doing this check in production.

Things I Don’t Want (Bad ORM)

• Automatic Model Generator – Not sure why, but code generators just strike me as a bad idea. My main issue here would be changes can’t be replicated to the generated files without overwriting manual changes that you might have made.
• Gimmicks – I don’t want features for the sake of features. I want a well thought out solution that is not bloated with every possible feature anyone could ever want.

• Doctrine
• Propel
• Outlet
• RedBean
• dORM
• Jelly
• Kohana ORM
• Sprig
• LightORM
• Flourish ORM
• php-activerecord
• CoughPHP
• Torpor