in reply to Input on Lightweight SQL Query Storage?

I'd probably never use this. With a package like Rose::DB::Object, I never have to think about the SQL at all for 95% of the common cases, and it's a lot more flexible.

-- Randal L. Schwartz, Perl hacker

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  • Comment on Re: Input on Lightweight SQL Query Templating?

Replies are listed 'Best First'.
Re^2: Input on Lightweight SQL Query Templating?
by Xenofur (Monk) on Apr 25, 2009 at 14:28 UTC
    Yeah, i considered using ORM, but honestly: SQL is a good language. It is well suited for what it's meant to do. I personally don't see a reason to introduce a lot of overhead on top of that only to have the benefit of writing SQL in Perl. (And the disadvantage of having to learn a completely new syntax only to express a language i already know.)

    As such this is meant for people who actually like SQL for what it is and simply want to keep it seperate from their Perl.
      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.
        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.
        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.