[Catalyst] C::P::A::Store::DBIC and Schema support

[Jess Robinson]

__PACKAGE__->config( { ... });

__PACKAGE__->setup;

__PACKAGE__->config->{authentication}{dbic}{dbic_schema} =
     __PACKAGE__->comp('DB::Anything');

.. I wonder that somebody didnt complain about this before now ;) Feel 
free to fix it to make more sense.

Jess


On Sun, 19 Feb 2006, Alex Kavanagh wrote:

> Hi Brandon
>
> Thanks for your response ...
>
> At Sun, 19 Feb 2006 09:38:54 -0600,
> Brandon Black wrote:
>>
>> On 2/19/06, Alex Kavanagh <alex at tinwood.homelinux.org> wrote:
>
> [snip]
>
>>> However, (obviously) this doesn't work.
>>>
>>> Anybody know how to configure this module to work with
>>> DBIx::Class::Schema ??
>>>
>>> My version of the schema support involved caching the '$c' when the
>>> 'User.pm' object was created in C::P...::DBIC.pm and this allowed me
>>> to use var->model( <config_model> ) where <config_model> was
>>> 'SiteDB::Users' and SiteDB was the namespace for the Schema.
>>>
>>> I can't quite work out where to get the Schema object from to get it
>>> into the config so that the Plugin will actually work.
>>>
>>
>> I don't know anything about the current implementation(s), but if I
>> were doing it, I'd probably have the config argument for the schema be
>> a model name rather than a schema class.  Anything that needs db
>> access in Cat should be using models rather than directly using
>> external stuff imho.  Your model could then be a C::M::DBIC::Schema
>> that has connection information.
>
> That's exactly what I did with my patch to the C::P::A::Store::DBIC
> modules.  I changed the config to be 'user_model' and made it
> 'SiteDB::Users' which was the schema namespace and table.  Then by
> keeping a ref to $c when the C::P::A::Store::DBIC::User object is
> created, do the Authentication check.  I figured it was okay to keep a
> ref to the $c because it was a Catalyst Plugin and wouldn't be used
> outside of Catalyst. (Is that true?)
>
> However, whilst I've been away, someone else has also patched this
> module set and done it in a way that I don't understand.  Inside that
> version of the ::User module it does this in C::P::A::S::D::User :
>
>     my $user_class = $config->{auth}->{dbic_schema}
>         ? $config->{auth}->{dbic_schema}->resultset( $config->{auth}->{user_class} )
>         : $config->{auth}->{user_class};
>     my $user_obj = $user_class->search( { $config->{auth}->{user_field} => $id } )->first;
>
>
> Therefore, I believe that $config->{auth}->{dbic_schema} *has* to be a
> DBIx::Class object and not just the class name.  i.e. it needs to be
> the object created by DBIx::Class's 'connect' method.
>
> My problem is that I would want to configure the module in my main
> site's Class thus (because this is more or less how the module's docs
> say to do it):
>
> __PACKAGE__->config->{authentication}->{dbic} = {
> 	       dbic_schema        => 'SiteDBIxSchema::Schema',
> 	       user_class         => 'Users',
>               user_field         => 'username',
>               password_field     => 'password',
>               password_type      => 'clear',  # will be 'hashed'
>               password_hash_type => 'SHA-1',
>           };
>
> Unfortunately, that doesn't work because 'resultset' want's an object
> and not a class name.  So I was wondering how anybody else has
> configured this module with the schema code in trunk?
>
> My version of the module that supports schema's is configured like
> this:
>
> __PACKAGE__->config->{authentication}->{dbic} = {
> 	       user_model         => 'SiteDB::Users',
>               user_field         => 'username',
>               password_field     => 'password',
>               password_type      => 'clear',  # will be 'hashed'
>               password_hash_type => 'SHA-1',
>           };
>
> And, this works.
>
> BUT, and it's a big but, my version isn't in trunk and thus, as it is
> later that the one in trunk, probably won't be adopted.  I have no
> problem with that, except that I can't work out how to efficiently
> (and not hackily**) configure the version that IS in trunk.  Unless I'm
> missing something obvious because I don't fully understand how all
> these modules work - and this is entirely possible, even likely.  My
> apologies if this is the case.
>
> ** I could hack it in by setting the config in a auto method - but it
>   seems SUCH a crap way of doing it.
>
> Thanks
> Alex.
>
> PS I'm holding off updating the pods on my patched version because it
> looks like it would be a waste if the above works.
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>
>