On Wed, May 4, 2011 at 3:55 AM, [email protected] <[email protected]> wrote: > Hi, > > I am using reference type property in one of the nodes, and noticed that > referenced node id along with all it's references (in blob) is stored in > ${schemaObjectPrefix}REFS table (I am using bundle persistance manager for > oracle). > > I don't see pointer to referenced node in the blob of referencing node. > > Does that mean that while getting referenced node from referencing node > (using node.getProperty(...) method) uses reverse lookup? If that is the > case wouldn't it perform extreamly poorly when there are millions of rows in > ${schemaObjectPrefix}REFS table each referenced by 100 of nodes? Since in > reverse lookup jackrabbit will have to triverse all rows in > ${schemaObjectPrefix}REFS table to find referencing node id in each row's > blob. > > Am I missing something?
yes. references are stored on the target. for every mix:referenceable node currently being referenced by 1-n reference properties there's one record in the REFS table. that record stores the collection of property id's refering to the corresponding mix:referenceable node. this approach was chosen in order to efficiently support referential integrity checking, both forward and reverse lookups are highly efficient. the drawback of this approach is limited scalability. 10k and more references to any particular node slow down write performance, i.e. adding an additional reference to a target node already being referenced by lets say 100k properties is relatively slow since the the entire collection of referer id's needs to be stored. cheers stefan > > Please elaborate. > > Thanks, > KS. > > -- > View this message in context: > http://jackrabbit.510166.n4.nabble.com/Jackrabbit-Reference-Lookup-tp3494206p3494206.html > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. >
