http://www.perlmonks.org?node_id=279149


in reply to Class::DBI Intro

A few comments.

Replies are listed 'Best First'.
Re: Re: Class::DBI Intro
by Corion (Pope) on Jul 30, 2003 at 12:38 UTC

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

Re: Re: Class::DBI Intro
by trs80 (Priest) on Jul 30, 2003 at 18:06 UTC
    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.
Re: Re: Class::DBI Intro
by salvadors (Pilgrim) on Aug 01, 2003 at 07:54 UTC

    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