Hacker News Reader

Comment by apsurd | Hacker News Reader

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.

View on HN

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.

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.

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.

The DataMapper ORM allows you to use SQL but still return domain objects: 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.

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.

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.

Using an ORM isn't the anti pattern here, using the row object instances as domain objects is.

Reply on news.ycombinator.com