Thanks. Response in-line.
On Mon, Nov 11, 2013 at 6:10 PM, Charlie Garrison <garri...@zeta.org.au>wrote: > Good afternoon, > > I'll open with disclaimer that I don't really know the answer, but I asked > the same question about 6 weeks ago with a new project (with lots of > similar components to an old project), and I muddled through to answer it > myself. I'll share my solution, and hope for more feedback from those who > know better than me. > > > On 11/11/13 at 4:55 PM -0800, Seth Daniel <dbix-cl...@sethdaniel.org> > wrote: > > If I'm wrong what is the best way to model having many shared >> columns/relationships over 2 or more tables without repeating myself? Is >> there a way in DBIx::Class to model where an A and B table "inherit" >> from a base table? Is there a good way to do this in DBIx::Class? Is >> this a good way to do this in DBix::Class? >> > > I Moosified all my DBIC classes and used the standard `extends` > functionality. In your example you will have 3 classes: > > Schema::RBase > Schema::Result::TableA > Schema::Result::TableB > > TableA and TableB will both `extend` RBase. All the shared column > definitions (& methods) go into RBase while everything table specific goes > into one of the other classes. > This works? I know I've tried this and I could never get it to work. DBIx::Class always complained about not being able to locate result_source_instance. DBix::Class::Manual::Troubleshooting mentions this error and what it means but I could never get sub-classing to work properly. I'd be very interested in seeing a working example. I clearly was doing something very wrong. The only problem with moosifying my own result classes is that I'm already using DBIx::Class::Candy. I love Candy because the result classes are so much easier to read and simply look prettier. But it doesn't seem to play well with Moose. But Moose isn't a requirement of sub-classing so probably not an issue. > > In my case, I have same/similar classes in different projects, so I > created new 'shared' module namespace (MyLib::Schema::RBase & RSBase). > Multiple projects will use classes from the shared lib. Use > `load_namespaces` to load classes from both the shared lib and your app's > lib. > > __PACKAGE__->load_namespaces( > default_resultset_class => "+MyLib::Schema::RSBase", > result_namespace => [ '+MyLib::Schema::Result', 'Result' ], > resultset_namespace => [ '+MyLib::Schema::ResultSet', 'ResultSet' > ], > ); > > It gets slightly tricky when defining relationships; some of them will > refer to the shared lib namespace, rather than app/schema namespace; > remember to check relationships carefully. Or just keep everything under > MyApp and keep it simple. > > __PACKAGE__->belongs_to( user => 'MyLib::Schema::Result::User', 'user_id'); > > > > A not entirely unrelated question: is there a preferred way to share >> column >> definitions among non-related tables? So if I want a username in one >> table >> and want the same definition for username in a different table is there a >> preferred way to share this definition among the result classes? I can >> think of several ways to do it but wondering if there is a best practice >> wrt DBIx::Class. >> > > Put the shared code/devinitions into a Moose role, and use that role > `with` your result class. I did that to share the same (postal) address > functionality across multiple classes. (I've become a big fan of Moose > roles. :-) ) > Using roles (or components) is how I was thinking of doing it. I wasn't certain if there was a better or more preferred way. Thank you for the help.
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk