[Dbix-class] best way to share schema elements?

[Seth Daniel]

Thanks.  Response in-line.


On Mon, Nov 11, 2013 at 6:10 PM, Charlie Garrison <garrison at zeta.org.au>wro=
te:

> 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-class at 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 =3D>   "+MyLib::Schema::RSBase",
>     result_namespace        =3D> [ '+MyLib::Schema::Result',    'Result' =
],
>     resultset_namespace     =3D> [ '+MyLib::Schema::ResultSet', 'ResultSe=
t'
> ],
> );
>
> 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 =3D> 'MyLib::Schema::Result::User', 'user_i=
d');
>
>
>
>  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20131112/c41=
a37a4/attachment.htm