Re^2: Class::DBI - my way is not very sportsmanlike

[jZed]

Are you aware of Class::DBI::Loader, and the Class::DBI output mode of SQL::Translator? Class::DBI::mysql/pg

Yes, thanks, good suggestions.

I'm not sure why you made the INSERT statement though.

Because I like my SQL to be explicit and visible and in one place and most of the data I deal with is in arrays, not hashes.

has_a() and has_many() ... have additional functionality that you're losing here.

I guess that's what I'm asking. What am I losing? Is what I'm losing just some nice shortcuts, or am I losing something essential to the kind of abstraction that Class::DBI supports?

[perrin]

If you dislike having SQL generated for you, you may be happier just using Ima::DBI directly. It doesn't turn your data into objects, but it sounds like you don't really care about that as much as setting the SQL manually.

If you do want to keep Class::DBI and set your INSERT manually, I think you can actually override the MakeNewObj SQL which is set through a set_sql call at the top of Class::DBI.

The has_many() stuff does a few things for you. It handles cascading deletes, gives you a method for adding a new related object (add_to_*), and lets you restrict the set ( $prof->subjects(year => 2003) ) or set an order.

Both has_many and has_a follow useful rules when fetching objects. They can turn your data into a Perl class (a DateTime object is the classic example), they use lazy-loading to avoid fetching data you don't usually need until you ask for it, and they will check to see if you already have any of the objects in memory and return the existing object instead of making a duplicate.

In short, Class::DBI has grown to do quite a bit. If you want a very lightweight way of accessing data and saving it back out, there are other options that might be simpler.

[jZed]

Thanks for all the info. I'm not looking for something lighter or simpler (I really do like Class::DBI), rather trying to figure out a good balance between "close to the SQL" style programming and "hide the SQL" style, they aren't mutually exclusive. The same goes for "close to the DBI style". For example, I can use Prof->search_query in some contexts and $sth=Prof->sql_query in other contexts with the same Class::DBI object (e.g. if I want to pass the $sth to DBI::Format or some other module that knows how to handle statement handles).

[thor]

Because I like my SQL to be explicit and visible and in one place and most of the data I deal with is in arrays, not hashes.

Easily rectified:

@hash{@keys} = @values;