Do you use an ORM outside a popular framework?

Im just wondering if anyone does this.

Because they are a rather large collection of files. I was looking at Doctrine and I liked it, but I think it’s pretty big!

It’s huge. So is Propel. They do more than I would want so I never use any of them I have only taken a readers interest in them.

Cheers,
Alex

ORMs are generally pretty large, but they don’t have to be. I have used phpDataMapper outside a framework with just plain old PHP files on a quick RSS consuming website I made called [URL=“http://allblizz.com”]AllBlizz. It’s probably one of the lightest and most basic websites I’ve done in a long time.

I do it for most of my projects. I have used Propel in the past but then I decided to write my own ORM because Propel was very heavy, slow and a pain to install and update models on db changes. I use my own one which is much lighter and has the features I need. The reason I use it is not to abstract sql but to have model objects to organize most of my code, add virtual or computed db fields, change update/insert logic, etc. I first create db tables and then within a press of a button in my generator script I have all my model objects ready where I begin to add my own stuff. I have found that many tasks are much easier to accomplish with db data in objects, like form editing or data validation. I also use plain sql whenever I need but most often I put the results into the model objects for convenience (known as hydrating in Propel). I don’t care about complex criteria objects (I use plain sql for that) or all kinds of relations being abstracted into the ORM - I don’t like when I have to spend most of my time learning how an ORM works instead of focusing on the task at hand. Therefore my ORM is not a full-fledged ORM because I don’t believe it’s worthwhile to convert all db relational logic into object logic - it can get very complicated, very abstract while still it’s not possible to run away from the underlying relational model - think about indexes for optimization, foreign keys and all other db specific nuances.

My requirements from an ORM are: light, relatively fast, easy to use and allowing to use plain SQL easily whenever I need. My main reason for using it are organization of code and convenience of working with data in objects.

I have read and fiddled around with Propel, Doctrine and phpDataMapper but have yet to use any in an actual project. At this point in in time I prefer the standard business separation approach using a model with SQL queries customized to the business tasks in hand normally returning multidimensional associative arrays rather than objects. At work I use Drupal and a content management system driven by C and its own template language. So I haven’t really had an opportunity to use any in a work environment outside my own personal experimentation.

I’ve used Doctrine as part of symfony, and I quite liked it, but it does have limitations. Outside of a framework, I don’t think I’d use anything like it.

I haven’t used an ORM but I’m really interested in how they cope with huge databases. I must admit, I don’t even know how Doctrine / Propel work internally and I didn’t check yet so if it’s not a problem for any of the members who are familiar with them - did you have any experiences with larger databases (over 10 gb) and ORMs?

I’m not that fond of full ORM’s. I like to keep my application code aware of the relational model underneath. I also like a low level of abstraction. In my experience, ORM’s cost a lot in this area.

I have used a home-weaved query-abstraction layer for a while. I have been giving it an overhaul during the holidays, making i it a bit more advanced, but it still doesn’t try to manage relations/identity that is the main cause of ORM’s complexity.

Is it available anywhere? Just curious.

+1 @ kyberfabrikken

I’ve tinkered with 3rd party ORM’s, but found they were too expensive in terms of resources for my tastes, and when you start factoring in relational queries beyond 1:1 table/class relationships you effectively learn SQL in another format, which IMO defeats the purpose.

I rolled my own purely to wrap up some convenience methods and to collect pre-baked SQL calls - i.e. getPostsByUserName() or getCompanyEmployees…I wouldn’t embark on this type of venture for production software, tinker with one in your spare time until it does what you want it to do, then you can think about leveraging it in your commercial work.

ORM’s are good for the first 30-50% of your db tasks, but suck for anything requiring complex queries.

I don’t think the size of the db matters as much as what kind of queries you run. If the queries are optimized then an ORM will cope with that. The problem is you may not know your queries are not optimized until your site gets slow because ORM’s hide sql. I have had experience with Propel and it was very difficult to debug what was actually sent to the db so most of the time we were programming happily with nice looking objects and methods not knowing what was going on under the hood. Then at certain times the site went down due to db server overload - we had to change several pieces of code to use plain sql and bypass Propel to gain proper control of db optimization.

There may be also problems when you select large collections of data, ORM’s will be much slower. At least in Propel there’s a lot of code processing each time you do even a simple query with objects so you can literally feel the overhead. Not good for high traffic sites.

No, I was thinking about it but I have to make it a standalone package for that - at the moment it’s part of my framework - and write some basic documentation. I can share the code with anyone who wants but currently it’s not in a form ready for a release.

I’m still evolving it, recently I have added support for magic getters and setters and am trying them now in my current project - so far that works pretty well. I have also started adding some auto-generated methods to work with related tables but I have found it to be a dangerous path of becoming an overcomplicated system like Propel - there are many obstacles on that path so I have stopped. It’s better to keep it simple.

Like many of the other posters I have tried various ORM packages but always ended up going back to a simple mapper type solution. Mostly because things tended to fall apart for anything but the simplest queries.

However, Doctrine 2.0 has now been released and I think they got it right. They had the courage to discard their 1.0 code tree and to start over from the ground up using PHP 5.3.

Here is an example of a DQL (Doctrine Query Language) statement:


    $dql = <<<EOT
SELECT event, partial field.{id,desc}, teams, schTeam, phyTeam
FROM \\OSSO\\EventItem event
LEFT JOIN  event.field     field
LEFT JOIN  event.teams     teams
LEFT JOIN  teams.schTeam   schTeam
LEFT JOIN  schTeam.phyTeam phyTeam

WHERE event.id IN (9909,9922)
EOT;

An event (think soccer game) has a 1:1 relation to a field. The partial key word allows me to restrict the field object to just id and description. And event has 1 or more teams, each team is linked to one schedule team which in turn links to a physical team.

The dql ends up getting converted to a nice compact sql statement. It all seems to work very nicely and is well worth taking a look at.

I had similar question on another post. Someone suggested ORM to have true DB abstraction (in sense that I can change databases quickly). And I read up on http://redbeanphp.com/#/Tutorial.

But then reading this tutorial, I am wondering if I should really do that. Because the app I am working on will be on MySQL and won’t change in the near future to other database. Even then, I’ll be using DataObjects (another lesson from that thread) so it might be very easy to change queries if need be.

Unless you plan on supporting (and testing) multiple databases right from the start then forget about the whole topic. Waste of time.

There are basically three reasons not use a full fledged ORM:

  1. Performance
  2. Capability
  3. Learning curve

Performance of course is very much application dependent. Capability is basically determining what your application really needs to do that the ORM does not support. And of course the learning curve depends on the learner, the documentation and the support community.

I’ve tinkered in writing my own ORM, which was basically an ActiveRecord pattern library but then I started looking at Doctrine 2 since its a lightweight compared to version 1.x. Doctrine has always been elegant but now it is also slim. So I am thinking about going to that soon.