Sorry about top posting, replying from my phone. This has mostly gotten off topic. I'm pretty sure that the real solution to the original question is to define the nullable rel with a join type of LEFT. If you need more help feel free to ask. On Jun 20, 2012 3:45 PM, "Kenneth S Mclane" <[email protected]> wrote:
> > Bill Moseley <[email protected]> wrote on 06/20/2012 02:00:57 PM: > > > From: > > > > Bill Moseley <[email protected]> > > > > To: > > > > "DBIx::Class user and developer list" <[email protected]> > > > > Date: > > > > 06/20/2012 02:05 PM > > > > Subject: > > > > Re: [Dbix-class] Search_rs not returning newly created rows > > > > On Wed, Jun 20, 2012 at 1:49 PM, Len Jaffe <[email protected]> > wrote: > > > > > On Wed, Jun 20, 2012 at 2:39 PM, Bill Moseley <[email protected]> wrote: > > > > I'd worry less about where your database calls are happening. Do > > you really care if [% user.address.city | html %] hits the database > > in the template or in the controller? > > Well, not caring where this happens tends to lead to the what you > > describe next. Why not put the address data in the stash? The model > > knows it will need to display it. > > > > A bit off the topic here. There's no perfect solution. I've > > unwound loops in Controllers, too. > > > > > > One point of the object abstraction is you don't care about the > > implementation. The real problem I've seen, though, is doing > > something stupid like huge nested loops in the template where each > > one generates a query. > > This is what I meant to about maintenance nightmare. > > > > I've inherited apps like this where I had to roll nested queries (in > > templates) up into a single query to go from 120 round-trips to the > > database, taking 8 seconds, into one round trip, taking half a second. > > > > L. > I solved the original problem by eliminating the prefetch call that was > creating an incorrect join and limiting the resultset. The page that lists > the accounts is one of my most expensive db calls, and it takes about a > third of a second to return data over a long distance remote connection, so > it's not much of an issue. I have a few fields where they did some fun > stuff with case statements and assigning a text string based on the > status/contenys of several different fields. I could not figure a way to > duplicate that without raw sql, so I built it into the template code. That > is truly an ugly way to do it. But, I had to balance that against the > business need. To spend the time to do it differently for the 4-6 users > that may hit the app a day didn't seem like a good investment of my time. > Once I have it up it is one of the things I will be revisiting. > _______________________________________________ > List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class > IRC: irc.perl.org#dbix-class > SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ > Searchable Archive: > http://www.grokbase.com/group/[email protected] >
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
