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

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

Comment on Re^5: Class::DBI vs. DBIx::Class

Replies are listed 'Best First'.
Re^6: Class::DBI vs. DBIx::Class by hrr (Monk) on Jun 25, 2006 at 21:51 UTC
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.	[reply] [d/l] [select]
Re^7: Class::DBI vs. DBIx::Class by rafl (Friar) on Jun 26, 2006 at 09:12 UTC
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	[reply]