Actually, if I have a Painting with a fault to an Artist and do a
painting.getArtist() (which will resolve the fault), I'd want to scan
the ObjectStore looking for Artists that are hollow/fault, regardless of
the registered paintings. For example, there could be a gallery/etc
that has faults to Artists, too. I'd like those to be picked up and
filled in, also. The basic premise being that if I have faults already,
I might need them around soon, so I might as well pay the expensive DB
trip to get more than one.
Of course, I'd prefer this to be a settable parameter somewhere
(DataContext?) with the default being 1 (current implementation -- get
only what was requested).
Basically, I'm trying to keep from doing 20,000 trips to the database to
display one web-based table (that's about our worst-case right now --
it's not an efficiently designed DB, but it is what it is).
I don't know how much time I'll have to work on that right now (higher
priorities/etc), but I think it could be really useful as an option.
Thanks!
/dev/mrg
PS. I just saw the message about giving Mike Kienenberger committer
status (I had forgotten to confirm my subscription to devel). I don't
know if I get a vote, but Mike has always been helpful to me and others
on the list and is obviously active with Cayenne. Sounds like a perfect
candidate to me.
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Tuesday, October 19, 2004 11:04 PM
To: Gentry, Michael
Cc: Cayenne Devel
Subject: Re: Batching faults?
I am taking this discussion to cayenne-devel...
I was actually thinking of bypassing the hollow object state for
simplicity. So at the moment when batch fault needs to be resolved, you
would scan existing ObjectStore and build the right query. E.g. if you
have a Painting and you detect that its Artist is a fault (and you want
to batch-fault 100 Artists with it), you'd look for other registered
Paintings (up to a 100) that have their target Artist either as a fault
or as a hollow object. You collect their ObjectIds, and do a fetch.
Of course it would be smarter to actually return a hollow object and
remember that it has to be batch-faulted on next access to its getter
or setter, but this really adds a layer of complexity for a little
benefit - an extra piece of cache to maintain (which might not be that
bad, still...) So my reasoning is that if you call
Painting.getArtist(), there is a 90% chance you'll end up calling
Painting.getArtist().getName() very soon :-).
Andrus
On Oct 19, 2004, at 4:59 PM, Gentry, Michael wrote:
> OK, I hope this isn't a silly question.
>
> To do my initial caching, I maintain a list of unfetched ObjectIds
> which
> I batch fetch in using QueryUtils.selectQueryForIds(List). If I get
> this custom batch faulting handler working, it would make more sense
(I
> think) to convert my caching mechanism over to using the custom batch
> faulting handler.
>
> What's the best way to create faults (or hollow objects) on my own?
> Would it be sufficient to create instances of the class, set the state
> to hollow, and then set the ObjectId (which I'm already creating)?
> Then
> the custom batch faulter could resolve those, too.
>
> Thanks,
>
> /dev/mrg
This archive was generated by hypermail 2.0.0 : Wed Oct 20 2004 - 10:52:19 EDT