What it comes down to is that hierarchical/graph-style data
structures are REALLY hard to do depth queries on with SQL ... Oracle
provides the "connect by" syntax that makes certain special cases
easier (but has huge restrictions), and getting that to play nicely
with EO probably would be a trick. I've tried a bunch of different
methods. If you don't mind fighting some battles with unnormalized
data, it honestly has been the best route that I've used so far (our
particular case is multi-parented, so it's a graph rather than a tree):
these names are obviously made totally generic here:
a Node table that stores the data that is on each node
a NodeStructure structure table that is (ParentNode, ChildNode,
DirectReferenceCount, IndirectReferenceCount)
when you put a child in a parent (direct child) you check for an
existing structure, if it exists, increment directrefcount, if it
doesn't, create a new one w/ directrefcount = 1
for each of the new parent's ancestors, you do the same thing for the
new child, but incrementing the indirectrefcount (so if A=>B, and you
add B=>C, there will be a new (B,C,1,0) and (A,C,0,1))
The code to manage these is obnoxious, but you only have to do it
once. The main benefit of this is structure is that you can do a
"flat" query to get all descendents (all ChildNodes where
NodeStructure.ParentNode = some ancestor gives you them all).
ms
On Jun 1, 2006, at 4:33 AM, Florijan Stamenkovic wrote:
Flor,
Two things spring to mind.
The first is to just have the entity cached in RAM via the setting
in EOModeler. Select the entity, inspect it, and go to the
advanced entity inspector (the second icon), and select the
checkbox at the bottom that says, "Cache in Memory". This will
pull in all of the snapshots for the entity, and then when you
traverse the tree the EO's are generated from the cached snapshots
and you avoid the round trip to the database. This works best if
you are going to traverse all of the trees and there aren't so
many individual EO's that you start running out of RAM.
Don't think this will go. These tree structures as one of the
central points in the db, and there is a lot hanging on them. They
are flexible and changeable, and their relationships to other
entities (mostly to-many) are continuously changing. And I never
really know which trees a certain client will need. Out of a
potentially large number of them. No go.
The second technique is to set a prefetching key path. This is
made really easy because you already have a single separate root
object that has a to-many relationship to all of the nodes of a
particular tree. Fetch that root node, but in the fetch
specification set a prefetching key path that follows the to-many
relationship and gets all of the nodes into memory in one round-
trip to the database. This works best if you are going to traverse
only one or a few of many trees, or if there are so many nodes
that you can't cache them all in memory.
Yes, this will probably work. I will have to change the way I get
my root objects (as at the moment I get them by resolving a
relationship), but besides that it should work.
Hope this helps.
Yup, hope so. Thanks a lot, also to everybody else who commented.
Cheers,
Flor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%
40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
