>From what I recall - the caching trait doesn't play with joins. From what I can tell - neither does H::FH; Can anyone confirm this? It might make more sense for your queries to always specify a deep join/prefetch option to reduce the number of queries.
I see this statement as well: > "This feature is new. It doesn't handle relationships yet, and the > interfaces are still subject to change." ... which leads me to believe that efficient joins aren't implemented http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/FormHandler/TraitFor/DBICFields.pm <http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/FormHandler/TraitFor/DBICFields.pm> cheers, -nw On Thu, Apr 14, 2011 at 10:53 AM, Hernan Lopes <[email protected]>wrote: > i remember you mentioned something about many to many select options, try > disabling those.. and then does the form works faster? > if so, then the problem is mostly like in there ... try populating your > options manually > > On Thu, Apr 14, 2011 at 1:15 PM, will trillich < > [email protected]> wrote: > >> On Wed, Apr 13, 2011 at 1:19 AM, Darren Duncan >> <[email protected]>wrote: >> >> will trillich wrote: >>> >>>> 70% of the time is taken up in five modules: >>>> 1) SQL::Abstract >>>> 2) DBIx::Class::ResultSet >>>> 3) Class::Accessor::Grouped >>>> 4) DBIx::Class::Storage::DBI >>>> 5) HTML::FormHandler::Field >>>> ...because in 200 iterations they were called millions of times each. >>>> (The form requested has several select/option menus.) >>>> >>> >>> So, several 5000s (millions / 200) of calls for a single screen? That >>> sounds like a lot for one screen. Do you need that much? -- Darren Duncan >> >> >> My question is similar -- why five thousand or more calls for rendering >> one page? The code does simple things like >> my $form = $self->form; >> # parse_form_for_numerics(): >> # change any $1,234 to 1234, parse 12-apr-09 to a date 2009-04-12, etc >> # and stuff results into $c->req->params >> &parse_form_for_numerics( $c, $form ); >> my $processed = $form->process( >> item => $item, >> params => $c->req->params, >> ); >> if ( $form->has_errors) { ... } >> return unless $processed; >> # since we're testing rendering a fresh page there's no processing, that's >> it >> >> So why would this simple code generate 5,000+ calls to SQL::Abstract >> methods >> or to DBIx::Class::Resultset methods? Even commenting-out >> #parse_form_for_numerics() >> it's about the same. Still looking into this. >> >> -- >> 11 cheers for binary! >> >> _______________________________________________ >> List: [email protected] >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/[email protected]/ >> Dev site: http://dev.catalyst.perl.org/ >> >> > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > >
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
