Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^3: Input on Lightweight SQL Query Templating?

by perrin (Chancellor)
on Apr 25, 2009 at 18:27 UTC ( #760047=note: print w/replies, xml ) Need Help??

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

You're misunderstanding the point of an ORM. It's not to avoid writing SQL, it's to avoid writing incredibly tedious SQL and DBI code that you've done a million times before. You still write the interesting SQL (reports and complex stuff where performance hinges on a specific SQL formulation) by hand.
  • Comment on Re^3: Input on Lightweight SQL Query Templating?

Replies are listed 'Best First'.
Re^4: Input on Lightweight SQL Query Templating?
by Xenofur (Monk) on Apr 26, 2009 at 15:27 UTC
    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 );
    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.

      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.

        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. :)
Re^4: Input on Lightweight SQL Query Templating?
by Anonymous Monk on Apr 28, 2009 at 11:44 UTC
    Something isn't right about that.

    If you don't like writing the same pattern over and over again, use an object and inject/pass some behaviour. Take a look at Spring Dao Templating.

    If you don't like writing set calc on your data, but rather write code, maybe you have a small point -- but you're gonna write something, be it SQL or ORM code.

      You're misinterpreting something. I don't need to write my own object, since the ORM code already exists. It handles the repetitive part of the work.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://760047]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2019-12-13 02:48 GMT
Find Nodes?
    Voting Booth?

    No recent polls found