Re: [Catalyst] Something wrong in Catalyst::Model::DBIC::Schema?

2011-02-25 Thread Oleg Kostyuk
Your model was generated by old DBIx::Class::Schema::Loader. Look at
http://cpansearch.perl.org/src/RKITOVER/DBIx-Class-Schema-Loader-0.07008/Changes
and search for moose for more details.

For fix, simply delete use MooseX::NonMoose from your schema class
(PTest::Schema).

HTH


2011/2/25 Alex Povolotsky tark...@over.ru:
 Hello!

 Freshly created application with out-of-the-box
 Catalyst::Model::DBIC::Schema-based model (nothing except creation with
 helper)fails to run, all modules are fresh.

 Application just does not run. Have I missed something?

 ./script/ptest_server.pl
 Couldn't load class (PTest) because: Couldn't instantiate component
 PTest::Model::Db, Couldn't load class (PTest::Schema) because: Can't call
 method isa on an undefined value at
 /usr/local/lib/perl5/site_perl/5.12.3/MooseX/NonMoose/Meta/Role/Class.pm
 line 40.
 Compilation failed in require at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP.pm line 114.
  at /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP.pm line 120
        Class::MOP::__ANON__('Can\'t call method isa on an undefined value
 at /usr/local/...') called at
 /usr/local/lib/perl5/site_perl/5.12.3/Try/Tiny.pm line 100
        Try::Tiny::try('CODE(0x804965738)',
 'Try::Tiny::Catch=REF(0x804ecf960)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP.pm line 125
        Class::MOP::load_first_existing_class('PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP.pm line 137
        Class::MOP::load_class('PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/Catalyst/Model/DBIC/Schema/Types.pm
 line 21
        Catalyst::Model::DBIC::Schema::Types::__ANON__('PTest::Schema')
 called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/TypeCoercion.pm line
 63
        Moose::Meta::TypeCoercion::__ANON__('PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/TypeCoercion.pm line
 97

  Moose::Meta::TypeCoercion::coerce('Moose::Meta::TypeCoercion=HASH(0x8049d6300)',
 'PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/TypeConstraint.pm line
 90

  Moose::Meta::TypeConstraint::coerce('Moose::Meta::TypeConstraint=HASH(0x804e70b28)',
 'PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/MooseX/Types/TypeDecorator.pm line 206
        eval {...} called at
 /usr/local/lib/perl5/site_perl/5.12.3/MooseX/Types/TypeDecorator.pm line 205

  MooseX::Types::TypeDecorator::AUTOLOAD('MooseX::Types::TypeDecorator=HASH(0x804e8b0a8)',
 'PTest::Schema') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/Attribute.pm line 880

  Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x804e66a80)',
 'PTest::Schema', 'PTest::Model::Db=HASH(0x804e72af8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/Attribute.pm line 483

  Moose::Meta::Attribute::initialize_instance_slot('Moose::Meta::Attribute=HASH(0x804e66a80)',
 'Moose::Meta::Instance=HASH(0x8049656c0)',
 'PTest::Model::Db=HASH(0x804e72af8)', 'HASH(0x804e71ac8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP/Class.pm line 603

  Class::MOP::Class::_construct_instance('Moose::Meta::Class=HASH(0x804e841f8)',
 'HASH(0x804e71ac8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP/Class.pm line 576
        Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x804e841f8)',
 'HASH(0x804e71ac8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Meta/Class.pm line 256

  Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x804e841f8)',
 'HASH(0x804e71ac8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Moose/Object.pm line 26
        Moose::Object::new('PTest::Model::Db', 'PTest', 'HASH(0x804eb1d68)')
 called at generated method (unknown origin) line 3
        Catalyst::Model::DBIC::Schema::new('PTest::Model::Db', 'PTest',
 'HASH(0x804eb1d68)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/MooseX/Traits/Pluggable.pm line 139

  MooseX::Traits::Pluggable::_build_instance_with_traits('PTest::Model::Db',
 'PTest::Model::Db', 'PTest') called at
 /usr/local/lib/perl5/site_perl/5.12.3/MooseX/Traits/Pluggable.pm line 97
        MooseX::Traits::Pluggable::new_with_traits('PTest::Model::Db',
 'PTest', 'HASH(0x8048a54f8)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/CatalystX/Component/Traits.pm line 145
        CatalystX::Component::Traits::COMPONENT('PTest::Model::Db', 'PTest',
 'HASH(0x80489d780)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP/Method/Wrapped.pm line
 48
        Class::MOP::Method::Wrapped::__ANON__('PTest::Model::Db', 'PTest',
 'HASH(0x80489d780)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/mach/Class/MOP/Method/Wrapped.pm line
 89
        Catalyst::Model::DBIC::Schema::COMPONENT('PTest::Model::Db', 'PTest',
 'HASH(0x80489d780)') called at
 /usr/local/lib/perl5/site_perl/5.12.3/Catalyst.pm line 2523
        eval {...} called at
 

Re: [Catalyst] Simple literal Model

2011-02-25 Thread John M. Dlugosz

 On 2/25/2011 4:06 AM, Tomas Doran bobtfish-at-bobtfish.net |Catalyst/Allow to 
home| wrote:


__PACKAGE__-meta-make_immutable;
1;

And you then call $c-model('Foo')-data;

The implementation of the 'data' method could then later be replaced by an attribute 
(i.e. has data = ( is = 'ro', isa = 'HashRef' );), and would then get the data from 
config, or something more complex (e.g. to get the data out of DBI, or another model, or 
whatever).


HTH
Cheers
t0m



Thanks.  Is '$c-model('Foo')-data' what something like DBIC gives us, too?  That is, is 
a method named 'data' the convention?  That is, if code was given a result set (I think 
that is the right term) of a query that was made on one of the main standard model types, 
what would the list of records look like?


Does 'MyApp_create.pl model' have any built-in stuff to generate a blank ad-hoc model like 
you showed me?


Thanks for the help.

--John



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Simple literal Model

2011-02-25 Thread Ashley Pond V
On Fri, Feb 25, 2011 at 2:27 AM, John M. Dlugosz wxju46g...@snkmail.com wrote:
  On 2/25/2011 4:06 AM, Tomas Doran bobtfish-at-bobtfish.net |Catalyst/Allow
 to home| wrote:

 __PACKAGE__-meta-make_immutable;
 1;

 And you then call $c-model('Foo')-data;

 The implementation of the 'data' method could then later be replaced by an
 attribute (i.e. has data = ( is = 'ro', isa = 'HashRef' );), and would
 then get the data from config, or something more complex (e.g. to get the
 data out of DBI, or another model, or whatever).

 HTH
 Cheers
 t0m

 Thanks.  Is '$c-model('Foo')-data' what something like DBIC gives us, too?
  That is, is a method named 'data' the convention?  That is, if code was
 given a result set (I think that is the right term) of a query that was
 made on one of the main standard model types, what would the list of records
 look like?


What t0m suggested is perfectly fine but if you want to mimic the DBIC
API with a different engine, this example does that (superficially and
as a tutorial only): http://sedition.com/a/2739 Log file model–Apache
access log. The reason that example makes sense is because the
underlying model/data is similar: searchable, sortable rows. If you're
trying to shoehorn in something dissimilar, you might be making a
mistake.

-Ashley

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Simple literal Model

2011-02-25 Thread John M. Dlugosz

 On 2/25/2011 9:30 AM, Ashley Pond V apv-at-sedition.com |Catalyst/Allow to 
home| wrote:

What t0m suggested is perfectly fine but if you want to mimic the DBIC
API with a different engine, this example does that (superficially and
as a tutorial only): http://sedition.com/a/2739 Log file model–Apache
access log. The reason that example makes sense is because the
underlying model/data is similar: searchable, sortable rows. If you're
trying to shoehorn in something dissimilar, you might be making a
mistake.

-Ashley

I'm not sure to what extent it is wise or correct.
The whole point of models is that it abstracts the model and I can change where the data 
comes from later, right?  So don't they all have an underlying abstract interface 
regardless of how they are sourced?
I can see that DBIC itself abstracts which database is used; e.g. SQL Lite for testing and 
MySQL on a dedicated server for deployment.  But I was thinking that the Model, over all, 
did a similar level of abstraction:  change from a database to a XML file or other 
representation, and the data is still presented the same way.


For example, I currently have 8 items, and want to just list them in Perl so I don't have 
to worry about another data representation or parsing it.  But if needs to become 
user-changable or grows to a few dozen items, a separate XML file would be better.  And if 
it grows to a search result of a few thousand items, it should be in a database.


Clearly there are differences in capabilities of a Model:  to wit, all in or 
searchable.  And a full database can return different results depending on selected 
columns, across joins, etc.  So I think the level of abstraction is that of a list of 
records.  The View is given a list of records, and the Controller knows to pull it by 
name directly, perform a search on a more complex model, or access an attribute of a more 
encompassing model.  It obtains the list and passes it to the View via the stash.


The examples I've read using DBIC use
[% WHILE ( item = list.next) %]
and I can imagine that in general we don't have efficient random access to the rows; in 
C++ I would characterize this as a forward iterator or even weaker, if I can't make a 
copy of the earlier state and go forward a second time.


I would have hoped that the TT [% FOREACH %] directive would work here.  That seems like 
the natural means of abstracting the list.  That is, the controller can set anything into 
the stash that FOREACH knows how to handle, including a plain Perl array.


So, is it an oversight of the documentation examples or of the framework that FOREACH 
isn't used on the DBIC result set?


--John


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/