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


in reply to Re: Class::DBI vs. DBIx::Class
in thread Class::DBI vs. DBIx::Class

Now I understand that DBIx::Class is more flexible than Class::DBI! On the other hand, this comes at the price of longer code for simple tasks, e.g., for inserting into a table 'Person', one would use 
# using DBIx::Class:  
$schema->resultset('Person')->new({FirstName=>'Joe'})->insert();   

# using Class::DBI:
DB::Person->insert({FirstName=>'Joe'});

[download]
Nevertheless, the greater flexibility motivated me to try DBIx::Class, too. What still bothers me is that 
package DB::Person;
use base 'DBIx::Class';
__PACKAGE__->load_components(qw/PK::Auto Core/);
__PACKAGE__->table('T_PERSON');
__PACKAGE__->add_columns(qw[PersonId FirstName]);
__PACKAGE__->set_primary_key('PersonId');

package DB;
use base 'DBIx::Class::Schema';
__PACKAGE__->load_classes(qw[Person]);

[download]
fails with Can't locate object method "result_source_instance" via package "DB/Person" (perhaps you forgot to load "DB/Person"?) at c:/Perl/site/lib/DBIx/Class/Schema.pm line 75. If I put the definition of DB::Person into DB/Person.pm, it works, but is far less elegant/compact. Is there a smarter solution?

Replies are listed 'Best First'.
Re^3: Class::DBI vs. DBIx::Class
by rafl (Friar) on Jun 25, 2006 at 15:20 UTC
    On the other hand, this comes at the price of longer code for simple tasks, e.g., for inserting into a table 'Person', one would use 
    # using DBIx::Class:  
$schema->resultset('Person')->new({FirstName=>'Joe'})->insert();  

# using Class::DBI:
DB::Person->insert({FirstName=>'Joe'});

    [download]

    How about:

    $schema->resultset('Person')->create({ FirstName => 'Joe' });

    [download]

    If you don't want to get the resultset from the schema first, you'll need to use DBIx::Class (DBIC) without a schema, which is usually called CDBI plain, but you'll then loose the advantages of the composable schemas, which, for example, allow you to connect to multiple databases from the same set of classes. I think using schemas is usually worth the overhead.

    I don't really know how to solve your problem with the posted snippet, but I suspect it's caused by the load_classes call. You can probably work that around with using register_class or register_source, but I haven't really looked into that as I don't like to ram up a single .pm file with several modules.

    Cheers, Flo

[reply]
[d/l]
[select]
      Thank you very much! register_class works well: 
      package DB;
map { __PACKAGE__->register_class($_, __PACKAGE__ . "::$_") } qw(Perso
+n);

      [download]
      Actually, connecting to single database is sufficient for me in most of the cases, so working without a schema would be great. How would I do this concretely? It did not find it in the documentation---apparently, working with a single database is (surprisingly) not very popular. Would I need to declare DB::Person as a subclass of ResultSource?
[reply]
[d/l]
[select]
        Actually, connecting to single database is sufficient for me in most of the cases, so working without a schema would be great. How would I do this concretely? It did not find it in the documentation---apparently, working with a single database is (surprisingly) not very popular. Would I need to declare DB::Person as a subclass of ResultSource?

        Take a look at DBIx::Class::DB. Even if you only want to connect to a single database only, it's strongly recommended to use a schema-based setup. Further explanations can be found in DBIx::Class::DB as well.

        What's your reason against a schema, except you might never need all the features, which is not a problem in my eyes? Is it too much work to write "$schema->" all the time? I could understand that, but there are better ways around this than to use the connection-as-classdata style like Class::DBI does.

        Cheers, Flo

[reply]

In Section Seekers of Perl Wisdom