Re^4: Migrating to DBIx::Class

I appreciate the time you've taken to respond, CountZero. I have some comments (as usual :-) )

1. While what you say is true in most cases, I can think of several examples where this doesn't apply. UNIONs, ALTER TABLE (while rare), and invocation of stored procedures in some DBs would fall into this category. Also, vendor-specific commands like SHOW TABLE STATUS in MySQL would require arbitrary SQL statements. If DBIx::Class can do this using the standard syntax, I'd be thrilled to learn how.

2. eval would work and it's a good suggestion, but it's inelegant and really, error handling should be built in. DBIx::Class seems well-written, at least from the outside, so I was hoping this was something on which I could rely.

3. Some DBs don't support views and this seems like a very hackish workaround for what should be a simple and common task. I did, however, discover that I can do most of what I want from DBIx::Class::Manual::Joining. I'm just not sure how to make a ResultSet that does this by default.

Comment on Re^4: Migrating to DBIx::Class Select or Download Code

Replies are listed 'Best First'.
Re^5: Migrating to DBIx::Class by CountZero (Bishop) on Mar 24, 2008 at 23:12 UTC
Perhaps it is a good idea to have a look at the DBIx::Class mailinglist. The real DBIx::Class-gurus hang out there. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^5: Migrating to DBIx::Class by Your Mother (Archbishop) on Jan 28, 2009 at 17:12 UTC
eval would work and it's a good suggestion, but it's inelegant and really, error handling should be built in. A function which returns any number of objects, some being exceptions, other being results is what I see as inelegance. Having to explicitly test every return value not just for success--which is an easy && good Perl idiom--but also for type is nasty. Error handling at the application level is nice, so it's done only once. Otherwise it is required at every level in every conceptual unit; a nice petri dish for spaghetti.	[reply]