in reply to Re^3: Input on Lightweight SQL Query Templating?
in thread Input on Lightweight SQL Query Storage?

I may be misunderstanding it. Or my mind just doesn't work right for it. Either way, I looked at Rose::DB:Object and the way to work with single objects already involves a ton of overhead. I could understand it though. Then I tried to find out how the hell i can do the following with it: 
$hash = $dbh->selectall_hashref( $query, $key );

[download]
I may show my own lack of intellect by saying this now, but the part of the documentation that SEEMED to explain it proceeded to jump straight into the deep end of the crazy pool, leading to a complete lack of understanding on my part as to why anyone would want to use it.

As far as i understand it and as demonstrated by DBI, this should be a hilariously simple problem to solve. But if I understood it right, Rose::DB solves it by having the dev create no less than 4 new packages and tags on an increase of RAM and CPU use by creating a new object for each row as well as navigating all the other object structures involved.

I completely acknowledge that I might be as fault, overlooking something, being ignorant over something or just plain being too stupid to get it. However as it stands now, I do not see how that makes "trivial stuff easier" when it seems to be doing the opposite. I am open to learn new things, so if you feel like explaining this, I'd love to hear it.

Replies are listed 'Best First'.
Re^5: Input on Lightweight SQL Query Templating?
by perrin (Chancellor) on Apr 27, 2009 at 15:23 UTC

    If you really need to do a straight SELECT and grab a bunch of data without making objects, then you can just get the dbh and do exactly what you did here. Nothing prevents it. What you were looking at is for people who want to get back a set of objects that can be written back to the db or have further queries performed on them.

    Common applications of DBI involve a lot of boring CRUD operations on single objects. Using Rose::DB::Object for these turns lots of boiler-plate code about tracking data changes, generating slightly different SQL for INSERT vs UPDATE and for just the columns which need to be written, preparing queries, and executing them with bind values, into one-liners.

    If you don't want to use an ORM, I'm not going to waste time trying to convince you, but I think you're way off the mark if you imagine the point of these tools is to avoid writing SQL. Like most reusable code, the point is to avoid repetitive and mindless work.

[reply]
      Sorry, but isn't the summary of what you just wrote: "Rose is good for single-row access, but when you want to operate on lots of data you're on your own."?

      My problem here isn't that I don't want to use ORM. Something that genuinely makes db access easier would be awesome. But whenever I look at ORM solutions they only seem to complicate things and so far nobody has been able to explain and/or demonstrate in plain english what the concrete advantage in a real world situation is.

      Also, as a sidenote: You may want to look into REPLACE, as it completely eleminates the need for slightly different insert and update instructions. :)
[reply]

        If you're doing mass updates or deletes, then an ORM is not typically going to help much. If you're grabbing a bunch of data, performing operations on each row, and writing it back to the db, an ORM can be a big time-saver.

        I don't know how to explain it any simpler than I already have. You'd have to try it. If you feel like the setup for Rose is too much, you can try Class::DBI. It's not as capable as Rose::DB::Object, but I still use it, and it makes direct SQL very simple.

        BTW, I usually avoid REPLACE. It's a slower way to do that operation than the alternatives and it makes DELETE triggers fire. If you're only supporting MySQL and you want to handle both cases with a single statement, INSERT...ON DUPLICATE KEY UPDATE is better.

[reply]

In Section Meditations