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

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.

Comment on Re^3: Class::DBI - my way is not very sportsmanlike

Replies are listed 'Best First'.

Re^4: Class::DBI - my way is not very sportsmanlike
by jZed (Prior) on Dec 03, 2004 at 17:27 UTC

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).

[reply]


Just another Perl shrine
	PerlMonks