5 ms·

I've never used an ORM, but I tend to associate their use with yer basic CRUD application that people write for money -- i.e. something not that interesting whe

by gavinpc 13y ago

I've never used an ORM, but I tend to associate their use with yer basic CRUD application that people write for money -- i.e. something not that interesting where you wouldn't mind "saving some time" if you could avoid caring exactly what string gets sent to the SQL engine -- or, perhaps, knowing SQL at all, for that matter. Am I wrong? Are people using ORM's in their "passion" projects? Or are they just a way to take some of the pain (and perhaps insecurity, think SQL injections) out of boilerplate apps?

timtadh 13y ago
I use SQL-Alchemy to help provide portability between SQLite and MySQL. That way I can run my apps in standalone mode or as part of a "real" deployment (nginx, uwsgi, python-app, mysql). SQl-Alchemy definitely helps take some of the pain out of that arrangement (although certainly not all of it). For some tasks I use the ORM layer of SA and for other tasks I just use their SQL Expression Language. I also appreciate all the work the SA devs have done to help mitigate SQL injection. I recommend using the SQL Expression Language without the ORM to help mitigate SQL injections (following from defense in depth). The oursql connector also helps with that as it supports real parameterized queries where as some of the other connectors do not.
timdev2 13y ago
I gave up on ORMs after a year or so (back around 2006) of ActiveRecord doing the "makes the easy even easier, makes the hard impossible" syndrome someone else mentioned. Then a couple of years ago, I started playing with a DataMapper/Unit-of-Work ORM (Doctrine2, in PHP-land). My experience, writing a moderately sized warehouse-management application, has been very good. In Doctrine, you don't write your schema/DDL. Doctrine does, based on your Entity and Association mapping. You write plain-old-PHP-objects, and then map their relations (in XML, annotations, or YAML). Doctrine reads and validates your data model, and generates DDL statements to create the schema. Big surprise: it creates pretty much exactly the same schema you'd expect. (And it will generate and manage migrations, too) Unit of Work is a powerful pattern, too, especially for web apps. You just worry about updating entities in memory. The ORM then flushes them to the datastore in a single transaction at the end of the request (so, by default, you have a one-to-one mapping between http requests and transactions in the RDBMS). Datamapper/UoW is probably overkill for CRUD stuff; that's where ActiveRecord shines. But it pays dividends when you're dealing with more complicated state-transitions on your underlying entities, and there are lots of cross-cutting concerns.
- kiksy 13y ago
  I read Jeff's article and the comments here with interest. My only experience with an ORM is Doctrine2 (about 2.5 years) , and I've never really hit any issues. Whenever I've needed to duck out using the ORM in an edge case, its only been a few lines of code and very undisruptive. In a recent project I manually mapped a large sprawling ancient schema manually using Doctrine2, and still never hit any major blockers. The code just abstracts away over the cracks. Does anyone have any real world example articles on where an ORM has totally failed, and why?
misterjangles 13y ago
I use an ORM that does basic mapping but let's you write your own SQL to cover situations that mismatch (still contained in a data layer of the app). It basically just saves a ton of time and let's me write a REST Services in about 2 minutes that power mobile apps or provide public/private APIs. I've used it for all variety of apps. I certainly do care what strings get sent to the Database though, I can tell you that! If you use an ORM and don't know how to inspect the queries it generates then I'd consider that to be somewhat negligent. That's just me, though.

by gavinpc 13y ago

timtadh 13y ago

I use SQL-Alchemy to help provide portability between SQLite and MySQL. That way I can run my apps in standalone mode or as part of a "real" deployment (nginx, uwsgi, python-app, mysql). SQl-Alchemy definitely helps take some of the pain out of that arrangement (although certainly not all of it). For some tasks I use the ORM layer of SA and for other tasks I just use their SQL Expression Language. I also appreciate all the work the SA devs have done to help mitigate SQL injection. I recommend using the SQL Expression Language without the ORM to help mitigate SQL injections (following from defense in depth). The oursql connector also helps with that as it supports real parameterized queries where as some of the other connectors do not.

timdev2 13y ago

I gave up on ORMs after a year or so (back around 2006) of ActiveRecord doing the "makes the easy even easier, makes the hard impossible" syndrome someone else mentioned. Then a couple of years ago, I started playing with a DataMapper/Unit-of-Work ORM (Doctrine2, in PHP-land). My experience, writing a moderately sized warehouse-management application, has been very good. In Doctrine, you don't write your schema/DDL. Doctrine does, based on your Entity and Association mapping. You write plain-old-PHP-objects, and then map their relations (in XML, annotations, or YAML). Doctrine reads and validates your data model, and generates DDL statements to create the schema. Big surprise: it creates pretty much exactly the same schema you'd expect. (And it will generate and manage migrations, too) Unit of Work is a powerful pattern, too, especially for web apps. You just worry about updating entities in memory. The ORM then flushes them to the datastore in a single transaction at the end of the request (so, by default, you have a one-to-one mapping between http requests and transactions in the RDBMS). Datamapper/UoW is probably overkill for CRUD stuff; that's where ActiveRecord shines. But it pays dividends when you're dealing with more complicated state-transitions on your underlying entities, and there are lots of cross-cutting concerns.

kiksy 13y ago
I read Jeff's article and the comments here with interest. My only experience with an ORM is Doctrine2 (about 2.5 years) , and I've never really hit any issues. Whenever I've needed to duck out using the ORM in an edge case, its only been a few lines of code and very undisruptive. In a recent project I manually mapped a large sprawling ancient schema manually using Doctrine2, and still never hit any major blockers. The code just abstracts away over the cracks. Does anyone have any real world example articles on where an ORM has totally failed, and why?

misterjangles 13y ago

I use an ORM that does basic mapping but let's you write your own SQL to cover situations that mismatch (still contained in a data layer of the app). It basically just saves a ton of time and let's me write a REST Services in about 2 minutes that power mobile apps or provide public/private APIs. I've used it for all variety of apps. I certainly do care what strings get sent to the Database though, I can tell you that! If you use an ORM and don't know how to inspect the queries it generates then I'd consider that to be somewhat negligent. That's just me, though.