On Oct 20, 2004, at 10:52 AM, Gentry, Michael wrote:
> 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).
Hmm... Maybe we should still approach it from the relationship
perspective. See, if you scan an ObjectStore, you can detect HOLLOW
objects, but all to-one relationship faults are represented by a shared
instance of org.objectstyle.cayenne.Fault.ToOneFault that is stateless
and doesn't store ObjectId information. So you really need to look for
the *sources* of given relationships to see if the target is
unresolved.
So if you mark one or more relationships from different entities to a
given entity as "batch fault", you can come up with a set of entities
to look for in order to detect faults for a given target... Plus
include the target entity hollow objects in the same query.
I suggest for the first pass of this feature make it external to
Cayenne (kind of a standalone handler object configurable outside the
modeler). I am still not clear when and how this will be plugged in to
Cayenne, but this shouldn't stop you from doing a "standalone"
implementation.
BTW do you think you can come up with a generalized description of a
case for faulting all objects of a given entity indiscriminately? I
still suspect that the most common case will be batch-faulting per
single relationship (ala EOF), as most UI table rows consist of a
master object and a number of details, so you can do targeted fetching
of only the objects you need. I understand you have a different case (a
mix of master entities in the same table?) So I guess we may implement
this as some sort of "strategy" that can be subclassed depending on the
app needs...
> 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.
Makes it a non-binding +1 ;-)
Andrus
This archive was generated by hypermail 2.0.0 : Wed Oct 20 2004 - 20:21:36 EDT