[CDBI] essential fields not populating as expected
jon at burdge.org
Tue May 1 01:32:57 BST 2007
Setting that does fix the problem in the example I provided, but
unfortunately this means $b->a->somedata will hit the database, even if
$a->somedata will not. This still leaves me with the issue I was trying to
solve in the first place. Maybe I'm just doing this wrong--is there a
better approach that I'm missing?
What I'd really like is a way to create more than one object from each row,
something like: "select b.*, a.* from b join a on b.a = a.aid" which would
return a list of B objects with the A objects all preloaded from the same
set of results. I haven't been able to find any examples on the wiki of
anything like this, though.
On 4/30/07, Bill Moseley <moseley at hank.org> wrote:
> On Mon, Apr 30, 2007 at 04:22:43PM -0700, Jon Burdge wrote:
> > The problem is that the second time $a is dumped, the somedata field is
> > loaded. This looks like the same problem I'm having with
> > have some objects already created that reference another table, and then
> > try to load the data for that other table, but the information from the
> > statement handle passed to sth_to_objects seems to be getting ignored in
> > favor of the stub object already in memory.
> Well, I remember the fix, but not the reason:
> $Class::DBI::Weaken_Is_Available = 0;
> It's not related to Essential, IIRC -- DBI->trace(1) should show that it's
> still fetching the "somedata" column in the retrieve. But, later
> calling $a->somedata makes it go back to the database for that column.
> But, I don't remember why it's doing that.
> Bill Moseley
> moseley at hank.org
> ClassDBI mailing list
> ClassDBI at lists.digitalcraftsmen.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ClassDBI