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 : Tue Oct 19 2004 - 23:04:29 EDT