Martin Aspeli wrote:
iirc, intid is fairly pluggable. for instance, if you still wanted to
use at style intids, you could just override the generation method in
the utility class and register your new class instead(though that would
make you unable to use the IBtrees that z3 index employ, iirc).
the integer id is more efficient for indexes(dig into the zcatalog and
you will find everything run off of integers).
> - Add the intid from five.intid as an index and metadata. This allows
> cross-referencing between the two.
This seems valuable. It already bridges the annoying gap where we don't
currently add UID to the standard catalog as an index or metadata.
We could possibly add a similar bridge in uid_catalog to make the
circle complete. I'd be happy if we moevd away from AT UIDs and
towards five.intid UIDs across the board, though.
before jensens bangs a drum about his UUids, I think we should make the
distinction between intid(really good for internal use) and other sorts
of UIDs that may be important for other kind of operations(global
merges, migration, etc).
fn:D. Whitfield Morriss
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
Framework-Team mailing list