difference between $c->user and $c->user->obj

when we use Catalyst::Plugin::Authentication::Store::DBIC::User, we will have $c->user and $c->user->obj. but most of people are confusing with them I guess.

differences:
* $c->user is ISA Catalyst::Plugin::Authentication::Store::DBIC::User, while $c->user->obj is just something like sub obj in Catalyst::Plugin::Authentication::Store::DBIC::User. see:

__PACKAGE__->mk_accessors(qw/id config obj store/);
# .skip
    bless {
        id     => $id,
        config => $config,
        obj    => $user_obj,
    }, $class;

* why $c->user->username is the same as $c->user->obj->username is because of

sub AUTOLOAD {
    my $self = shift;
    (my $method) = (our $AUTOLOAD =~ /([^:]+)$/);
    return if $method eq "DESTROY";

    $self->obj->$method(@_);
}

. when we call ->username of $c->user. it will call sub username in Catalyst::Plugin::Authentication::Store::DBIC::User. then sub AUTOLOAD works here, it call $self->obj->$method(@_) indeed. ($self is $c->user).

so there is something interesting..
* because we have sub for_session in Catalyst::Plugin::Authentication::Store::DBIC::User, we will have $c->user->for_session ( but not $c->user->obj->for_session if user table don't have "for_session" column ).
* when I see something "*user = \&obj;" in the code. I know I can use $c->user->user->username. it's the same as $c->user->obj->username. (JOKE!)

for most situation. I suggest use $c->user->obj->column_name because that's more direct (no AUTOLOAD involved).

Enjoy!.

Catalyst and DBIx-Class tip

* Catalyst Tip: use set_authenticated instead of login when password is SHA1 hashed.

well, Foorum use SHA1 to encrypt the password. so no one knows the original password including me (db do not store original password).
so if u are trying $c->login($username, $password_sha1_hashed);, it will fail.
if u are checking the module of Catalyst::Plugin::Authentication::Credential::Password which sub login is there, we would know the solution:
$c->set_authenticated($user);

that does the same as login but no password check.

* DBIx::Class Tip: attribute offset.

sometimes when we run a SQL, that's not something like LIMIT 0,6 LIMIT 6,6
it might be something like LIMIT 5,6
well, the attributes of "rows" and "page" does something like LIMIT 6,6. but no luck with 5,6.
so if u want run a SQL with LIMIT 5,6, u might can try

search( {}, {
    rows => 6,
    offset => 5
} );

that would be what u want.

be careful, offset do no create a Data::Page object for you. I mean ->pager. u need create that yourself.

Enjoy!

be careful

my @a = ( 'a', $c->req->param('a'), 'b', $c->req->param('b'), 'c', undef , 'd',, 'f' );$c->res->body(Dumper(\@a));

when we try "?b=1", output:

$VAR1 = [
          'a',
          'b',
          '1',
          'c',
          undef,
          'd',
          'f'
        ];

see? $c->req->param('a') is NOT undef.
so when u try something like

$rs->update( {
    column1 => $c->req->param('column1'),
    column2 => $c->req->param('column2')
} );

then if column1 param is not specified, this would raise error because $rs try to update column1, column2, $c->req->param('column2'). we want 4 but u give me 3.

so man, be careful of that. :)