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. | [reply] [Watch: Dir/Any] [d/l] |
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] [Watch: Dir/Any] |
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] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] |