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


Zope3-users mailing list

Reply via email to