Martijn Pieters wrote:
> On 17. juni. 2008, at 13.05, Philipp von Weitershausen wrote:
>> I don't understand why there would be data loss. You don't have to
>> reinstantiate an object just to re-register it (see below). You *do*
>> probably want to un-register first before re-registering in case
>> registration details changed (e.g. the name or provided interface).
>
> But the GenericSetup components step does just that, see https://bugs.launchpad.net/zope-cmf/+bug/240170
> . I do think that there is enough info available there to determine if
> the registration doesn't need to be re-run though. I think Wichert is
> chasing a red herring here, personally ;-)
I gather from this bug report of yours that GenericSetup does NOT do
this yet but you'd like it to... Surely sm.registeredUtilities() equips
GenericSetup with enough information to check whether a new registration
must be made, an existing must be modified (IOW, unregister +
reregister) or nothing has changed.
So, can we close this bug then?
> Wouldn't it be a tad ineffecient to have to loop over all
> registrations to find information for one or at most a few utilities?
registeredUtilities() only loops over the registrations made with *this
particular* site manager. How many local tools does a CMF site have? 20?
30? So really not that many.
Plus, you're going to have to loop over the data structures *somewhere*
to filter out the ones you like, so I don't really see a way to
magically optimize this (unless the internal data structures of the
component registry was changed). But I call premature optimization on
this one :) It's not like you need to do this with every request, this
just needs to be done once during a GenericSetup step.
Martijn Pieters wrote: /bugs.launchpad .net/zope- cmf/+bug/ 240170
> On 17. juni. 2008, at 13.05, Philipp von Weitershausen wrote:
>> I don't understand why there would be data loss. You don't have to
>> reinstantiate an object just to re-register it (see below). You *do*
>> probably want to un-register first before re-registering in case
>> registration details changed (e.g. the name or provided interface).
>
> But the GenericSetup components step does just that, see https:/
> . I do think that there is enough info available there to determine if
> the registration doesn't need to be re-run though. I think Wichert is
> chasing a red herring here, personally ;-)
I gather from this bug report of yours that GenericSetup does NOT do ilities( ) equips
this yet but you'd like it to... Surely sm.registeredUt
GenericSetup with enough information to check whether a new registration
must be made, an existing must be modified (IOW, unregister +
reregister) or nothing has changed.
So, can we close this bug then?
> Wouldn't it be a tad ineffecient to have to loop over all
> registrations to find information for one or at most a few utilities?
registeredUtili ties() only loops over the registrations made with *this
particular* site manager. How many local tools does a CMF site have? 20?
30? So really not that many.
Plus, you're going to have to loop over the data structures *somewhere*
to filter out the ones you like, so I don't really see a way to
magically optimize this (unless the internal data structures of the
component registry was changed). But I call premature optimization on
this one :) It's not like you need to do this with every request, this
just needs to be done once during a GenericSetup step.