Stephan Richter wrote:
On Thursday 05 April 2007 15:28, Jürgen Kartnaller wrote:
Please do not use an annotation!
This is a performance issue. Your data is very small so do not create a
new object in the database store it directly as a property on the
instance. Every object lookup is expensive, especially if you use ZEO!
Hey Juergen, come on! I know you guys are on an optimization trip at Lovely,
but this is great information to store on an annotation. The UUID does not
usually need to be looked up and is mainly for external world reference, such
as feeds like Derek metioned he wanted.
The package is also an add-on. You don't need it, then do not use it. As
further optimization, Derek mainly needs this id for a very specific set of
content types, so I would narrow the subscriber to only give those special
types a UUID.
My use case is very constrained - I need UUIDs for syndicated objects
only. So, potentially, I could just generate and assign them when
content is syndicated and keep them in an annotation I'm already using
However, as Martin Aspeli mentioned, this functionality seems ripe for a
general-purpose package. If I split it out into its own add-on, it's
more work for me but perhaps generally useful. I've seen past buzz about
UUIDs in Zope, but it seems nothing has ever come of it.
My question is: are there potential use cases, outside of my own, that
justify the extra work to make it a separate add-on? And, if so, what
are these use cases and what do I need to do to support them? I could
see that there might be performance-sensitive applications that would
need UUIDs on many objects, but I don't know of one. Does anyone else?
The scenario I'm most trying to avoid is several different packages
implementing UUIDs and objects getting multiple UUIDs, one from each
package, all implemented different ways, because of the lack of a
Zope3-users mailing list