Forum OpenACS Development: Response to New implementation of tree_sortkey

Collapse
Posted by Don Baccus on
Thanks for the feedback, I've been hoping you'd have time to dig into this ...

First of all, thanks for correcting my misunderstanding about the text sortkeys version, I thought they were limited to two characters per level.

I had considered going to three or four bytes for the "wide" tree representation but had assumed the object tree would be more "branchy" than you do. My choice would be to keep the single bit "short or long" encoding and going to three for four bytes if we feel we should do that. My reasoning is that bboard, file storage and other content-oriented packages will naturally build trees in the content repository that will be "branchy" and it would be nice to stick with single-byte keys in such cases as much as possible.

We should decide this soon ...

(for those following the conversation who aren't intimate with variuos bits and pieces of OpenACS 4 there's one sort key placing such objects in the object tree, and another placing them in the CR folder tree).

As far as the function issue, I wasn't thinking of the replacement you suggest, i.e.

testtree=# select o.*
testtree-#  from tree_view o,
testtree-#    (select tree_ancestor_keys((select tree_sortkey from acs_objects where object_id = 2051)) as tree_sortkey) parents
testtree-#  where o.tree_sortkey = parents.tree_sortkey;
But rather other ways of casting the query that I'd tried at first that led to PG complaining that I was using tree_ancestor_keys in ways that it didn't like. The important point is that you have to grab the ancestor keys in a separate subselect and aren't able to combine this with anything else. At least all my attempts to do otherwise failed.

Which is cleaner? Your way's probably slightly faster, my way isolates things a bit better perhaps. Half a dozen of one, six of the other, pretty much?

And thanks for the compliment. I'd stumbled across the fact that BETWEEN would use an index while playing around with the problems we faced due to the unforseen fact that "LIKE" with a non-constant right operand correctly ignores the index. Having made that change I then searched for another data type that would work, and stumbled across BIT VARYING and after reading some PG sources, the fact that operations on byte-aligned ones are very fast.

So it's still really your implementation, it's just heavily disguised!