[Zope3-Users] Re: RFC 4122 UUIDs

[Derek Richardson]

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.
> 
> Regards,
> Stephan

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 
for syndication.

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 
general solution.

Derek