4 ms·

Nonsense. Everything is overridable. ORMs are perfect for a whole lot of standard cases and nobody prevents you from writing SQL code for custom cases and perfo

Nonsense. Everything is overridable. ORMs are perfect for a whole lot of standard cases and nobody prevents you from writing SQL code for custom cases and performance improvements.

apsurd 15y ago
we use Datamapper at work and have an increasing need to write custom sql queries. A common problem we face is that we now have non-standardized data coming out of the model. In other words does this method return a datamapper object or is it an array of custom-defined fields ? a quick fix would be to use the custom query to return ids and then use those ids to perform a Datamapper query that returns DM objects - which is clearly not a good programming practice. In my experience this article is spot on. It's easy to say "oh sure just use custom sql for this edge case" Only those edge cases turn out to be increasingly common and it is increasingly hard to work with data that may be coming at you in multiple formats.
- adaml_623 15y ago
  So your data is coming back at you in 2 different formats. We have the same issue and while it's not wonderful it's certainly not the end of the world. Naming conventions can help you know the return type of functions. And if you understand the types of queries being done under the hood by your ORM then sometimes using a custom query to retrieve ids to be used in a simpler ORM query is not such a bad idea. I think it's a case of doing things consistently in your code base so you use your ORM when it helps you and don't fight it when it's not going to help you.
- div 15y ago
  If you use the second solution mentioned in the article and just use only sql in your model, you would end up with a more varied amount of non-standardized data coming out. The other existing solution provided by the author is to switch to a key-value datastore, which still would not solve your problem.
- regularfry 15y ago
  Using an ORM isn't the anti pattern here, using the row object instances as domain objects is.
- andybak 15y ago
  There's no reason why an ORM can't allow custom SQL and still produce the same output format. Or close enough that duck typing will get you the rest of the way. I've done this several times using Django's ORM.
- Daishiman 15y ago
  The problem is that, plainly, your ORM sucks. Serious ORMS allow you to inject custom SQL and still return objects; many can just take the result of a plain SQL query and map it to objects as you please. Really, there are good and bad ORMs. Bad ORMs produce the results you mention. Good ones are much more adaptable.
  - dkubb 15y ago
    The DataMapper ORM allows you to use SQL but still return domain objects: http://rubydoc.info/github/datamapper/dm-ar-finders/master/DataMapper/Model:find_by_sql http://rubydoc.info/github/datamapper/dm-ar-finders/master/D... Maybe the gp doesn't know about it or chooses not to use it, but it exists.
    - apsurd 15y ago
      thanks for this! You are right I had no idea this existed. Just goes to show I really should read the source over depending on datamapper.org/docs/ too much.

Nonsense. Everything is overridable. ORMs are perfect for a whole lot of standard cases and nobody prevents you from writing SQL code for custom cases and performance improvements.

apsurd 15y ago

we use Datamapper at work and have an increasing need to write custom sql queries. A common problem we face is that we now have non-standardized data coming out of the model. In other words does this method return a datamapper object or is it an array of custom-defined fields ? a quick fix would be to use the custom query to return ids and then use those ids to perform a Datamapper query that returns DM objects - which is clearly not a good programming practice. In my experience this article is spot on. It's easy to say "oh sure just use custom sql for this edge case" Only those edge cases turn out to be increasingly common and it is increasingly hard to work with data that may be coming at you in multiple formats.

adaml_623 15y ago
So your data is coming back at you in 2 different formats. We have the same issue and while it's not wonderful it's certainly not the end of the world. Naming conventions can help you know the return type of functions. And if you understand the types of queries being done under the hood by your ORM then sometimes using a custom query to retrieve ids to be used in a simpler ORM query is not such a bad idea. I think it's a case of doing things consistently in your code base so you use your ORM when it helps you and don't fight it when it's not going to help you.
div 15y ago
If you use the second solution mentioned in the article and just use only sql in your model, you would end up with a more varied amount of non-standardized data coming out. The other existing solution provided by the author is to switch to a key-value datastore, which still would not solve your problem.
regularfry 15y ago
Using an ORM isn't the anti pattern here, using the row object instances as domain objects is.
andybak 15y ago
There's no reason why an ORM can't allow custom SQL and still produce the same output format. Or close enough that duck typing will get you the rest of the way. I've done this several times using Django's ORM.
Daishiman 15y ago
The problem is that, plainly, your ORM sucks. Serious ORMS allow you to inject custom SQL and still return objects; many can just take the result of a plain SQL query and map it to objects as you please. Really, there are good and bad ORMs. Bad ORMs produce the results you mention. Good ones are much more adaptable.
- dkubb 15y ago
  The DataMapper ORM allows you to use SQL but still return domain objects: http://rubydoc.info/github/datamapper/dm-ar-finders/master/DataMapper/Model:find_by_sql http://rubydoc.info/github/datamapper/dm-ar-finders/master/D... Maybe the gp doesn't know about it or chooses not to use it, but it exists.
  - apsurd 15y ago
    thanks for this! You are right I had no idea this existed. Just goes to show I really should read the source over depending on datamapper.org/docs/ too much.