Re: Class::DBI Intro

[dbwiz]

A few comments.

• In your connection to DBI, you are testing "$!". Be aware that this won't work as you expect. See the relevant info from DBI docs.
  

  If the connect fails (see below), it returns "undef" and sets both "$DBI::err" and "$DBI::errstr". (It does not set "$!", etc.) You should generally test the return status of "connect" and "print $DBI::errstr" if it has failed.

• The delete method is rather inefficient. When called, Class::DBI will issue one DELETE statement for each row in your table. Instead of producing
  

  DELETE FROM page WHERE user_id = 1
  DELETE FROM user WHERE user_id = 1
  

  It does
  

  DELETE FROM   page WHERE  page_id = '1'
  DELETE FROM   page WHERE  page_id = '2'
  DELETE FROM   page WHERE  page_id = '3'
  DELETE FROM   page WHERE  page_id = '4'
  DELETE FROM   page WHERE  page_id = '5'
  DELETE FROM   user WHERE  user_id = '1'
  

  which can be quite long for large data sets.
  The sad thing is that, even if I use a database that enforces referential integrity, Class::DBI will still override the database features and issue the same DELETE statements. In your example, if you replace the table definition to use the InnoDB table type, adding
  

  FOREIGN KEY (user_id) references user (user_id) ON DELETE CASCADE,
  KEY user_id (user_id)
  # and replace "MyISAM" with "InnoDB" for both tables
  

  You can then get the same behavior with

  %dbh->do("DELETE FROM user WHERE user_id=1")

  and the database engine will take care of cascade deletiing the appropriate records in "page".

• You said nothing about how DBI::Class handles queries with one or more JOIN, which are quite common in a production environment. This article would be much better if you explained how it works. Without it, it seems no more than an interesting toy.

[Corion]

I think you are looking at Class::DBI from the wrong angle - Class::DBI is not a tool to force existing tables (and their relations) into classes/objects, but to provide some simplicistic way of storing objects in tables.

Class::DBI isa Ima::DBI and thus has support for adding custom SQL constructors if you need to create an object resp. find an object through a complex query which you don't want/can't reproduce via Perl.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web

[mojotoad]

I think you are looking at Class::DBI from the wrong angle - Class::DBI is not a tool to force existing tables (and their relations) into classes/objects, but to provide some simplicistic way of storing objects in tables.

My thoughts were the exact opposite -- Class::DBI is an abstraction layer that let's you interact with your tables as objects. Throughout the documentation, when the author refers to 'objects' he generally means 'rows'.

Not that you can't do that. I'm only saying that Class::DBI is not going to necessarily make it easer to represent class inheritance in a relational system.

Matt

[trs80]

I corrected the connection test as you suggested, don't know how that slipped by.

Your second point is a good one, but eliminates the need for Class::DBI in that context. Class::DBI is not an end all be all for relationship integrity management. Class::DBI can however be used to manage relationships in situations where
1. The management of relationships has to be done at an application level vs. the database (somewhat database engine agnostic design)
2. The the database doesn't support more robust features, for which there are numerous examples and converting table format isn't an available solution because *insert subjective reason here*

"You said nothing about how DBI::Class handles queries with one or more JOIN"

Yes Class::DBI has many features and transparent SQL is one of them, but they are not within the context of an introduction. I plan to release a mid range tutorial after I complete my present project using Class::DBI. I am open for suggestions and or tidbits of what should be included in that node.

[salvadors]

The delete method is rather inefficient. When called, Class::DBI will issue one DELETE statement for each row in your table.

Yes. This is a deliberate design decision. The class in question may have explicit behaviours attached to the act of deleting (for example, you can set up triggers at the application level, rather than at the database.) The only way to cause these to be fired is to delete the objects one at a time.

It's fairly trivial to set up your own method to delete from the database in one pass if you're comfortable doing so. Replacing all your SQL is not really Class::DBI's goal. Its job is to remove all the boring trivial repetitive SQL from your application, freeing you up to spend the time writing the more advanced stuff yourself that can't be easily abstracted away.

Tony