> from the silence after my last question
Hard to tell much from that. There are far fewer active participants on
this list than on, say, your average Zope list, and sometimes they're all
> i deduct that there is no zodb-optimized list type that preserves list
That much is true, yes.
> if that's actually the case, i'll have to use OOTreeSet and their .keys()
> for those oid lists where i don't care about ordering and still use
> PersistentLists for those where i care about ordering.
Don't know enough about your app to judge tradeoffs for you. Since "a list"
is essentially an implicit mapping from integers to values, you could also
use an explicit mapping. For example, an IOBTree mapping an index to the
value "at" that index, or an OOTreeSet of
pairs (2-tuples). An interesting variation might be to use an OOBTree
mapping floats to values; then you could, e.g., efficiently insert a new
value "in the middle" by giving it an index that's the average of the keys
on either side of it. For example, if you want to insert an item between
"indices" 101.0 and 102.0, give it index 101.5.
> to make as little code changes necessary as possible, is it a good plan
> to have a OidList class with two sublcasses
> OrderedOidList(PersistentList) and UnOrderedOidListsubclass(OOTreeSet)
> and give them a list like protocol (.add(), .remove(), .has())
No matter which approach you take, it requires no code changes from me ;-)
Seriously, only you can judge this.
Note that list.remove() is rarely a good idea in any case. Python offers it
as a convenience, but its runtime performance is atrocious (time linear in
the number of list elements). I'm not sure what .has() means to you, but if
it means "does the list contain the argument?", that's a similarly bad
performer. While membership testing and removal are inefficient for lists,
they are efficient for BTree-based structures (time logarithmic in the
number of tree/treeset elements).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org