Re^4: Class::DBI vs. DBIx::Class

[hrr]

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

Thank you very much! register_class works well:

package DB;
map { __PACKAGE__->register_class($_, __PACKAGE__ . "::$_") } qw(Perso
+n);

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?

[rafl]

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

[hrr]

Thank you for the reference and for the warning. As you have suspected, it is "$schema->" that is bothering me. Writing it is not the problem, but it makes reading a bit harder, especially because it increases the chances that an expression does not fit on one line...

You say that there are better ways around it. Did you have something like sub resultset { $schema->resultset(@_) } in mind? This would indeed be a reasonable resolution of my concerns.

[rafl]

You say that there are better ways around it. Did you have something like sub resultset { $schema->resultset(@_) } in mind? This would indeed be a reasonable resolution of my concerns.

That's one solution that came to my mind, but as long as you keep the schema object around to be able to do transactions and stuff every solution that works around your problems is fine in my eyes.

Cheers, Flo