Forum OpenACS Development: Re: acs_object__new slowness...

Collapse
Posted by Don Baccus on
Originally I'd planned to use the security object (-4) to store the root leaf value when the context_id was null but ...

Is there any reason you couldn't just use the object id in this case?  It is unique and increases, the two attributes needed for the sortkey.

The only reason for generating adjacent keys at each level is to save space for skinny, deep trees (8 bits per level) ... clearly on big systems there will be more than 127 nodes at the root level so this isn't much of an issue for objects which have the root or null as parent!

Remember we need well-tested upgrade scripts if you're going to squeeze this into 5.0.

Collapse
Posted by Jeff Davis on
Don, I like using the object_id but the problem is updates on an existing site where the heirarchy was created with the old style key mechanism
Node  ObjID   Context SortKey
A     1       null    1
  B   2       1       1.1
C     3       null    2
If you wanted to update B's context_id to null you couldn't assume it's object_id was available since it had been used by C for its sortkey.

Of course on insert it should be ok (although it's conceivable that if a site juggled it's context_ids around enough the tree_sortkey could have walked past the object_id sequence but I don't think that it has ever or would ever happen). To be certain and safe though you would need to bump the object_id past the max tree_sortkey if it had, and when updating context_id to null you would need to take a nextval(object_id) although use it just for the sortkey rather than as the actual object_id.