OK, I can see your point of view. Option 1: Add an update_metadata flag to the catalogObject method with a default of True on all branches.
Option 2: Do nothing, but add the "updateMetadata" method to the ZCatalog interface. Option 1 would only take effect when 2.6.3 was released (if ever) and 2.7 final would have the new flag. Because since the behavior change has already been released in 2.6.2, it might be better to do option 2 and fix the places in CMF/SilvaMetadata that specify indexes, leaving it the way it is. Thanks, - C On Mon, 2003-10-06 at 06:24, Yuppie wrote: > Hi Chris! > > > Chris McDonough wrote: > > The system is making the assumption that if you update indexes > > individually, you know what you're doing. Passing an index name into > > catalogObject was always meant to do as much or as little work as you > > specified with respect to the names of the indexes; it was only by > > mistake that metadata got updated when indexes were specified. The new > > (correct) behavior may break some applications that depended on the bug, > > and I'm sorry it broke yours, but it was indeed a bug. > > Thanks for clarifying this! Now I understand why you changed it this > way. But I still don't agree you fixed a bug. From my point of view this > was an API change. > > > 1.) The interface (IZCatalog.py) > > a.) "If provided, idxs specifies the names of indexes to update." No > different behavior regarding metadata update is mentioned. > > b.) There is no other interface method to update metadata, so > catalog_object is responsible for keeping metadata in sync. > > > 2.) The use cases > > a.) Change of many object attributes or big attributes like 'body'. > Everything should be updated, works like before. > > b.) Dieter described this already: > >>The "idxs" argument is often provided to update only special indexes: > >>e.g. workflow indexes or "AllowedRolesAndUsers" and when you > >>update selected indexes from the "Indexes" tab. > >>In these cases, it is often not necessary to update the Metadata. > > c.) Change of metadata. Before you 'fixed' catalog_object, it was > possible to edit and reindex metadata like Description without > reindexing the whole PDF / Word body of a file. Now this expensive task > has to be perfomed after each metadata change. > > > 3.) The existing code > > a.) CMF. Not badly broken, but the metadata of new content items is now > wrong. This line in TypesTool.py doesn't work as expected: > > ob.reindexObject(idxs=['portal_type', 'Type']) > > b.) SilvaMetadata. The reindex code seems to be broken: > <http://cvs.infrae.com/SilvaMetadata/Binding.py?rev=1.39&content-type=text/vnd.viewcvs-markup> > > > Adding an 'update_metadata' flag would have been backwards compatible > and useful for each use case. > > > > And, doh, yes, I need to forward-port the fix to the 2.7 branch and the > > HEAD. :-( > > I saw you were working on sunday. At least this time you mentioned the > change in CHANGES.txt... > > > Cheers, > Yuppie > > > > _______________________________________________ > Zope-Dev maillist - [EMAIL PROTECTED] > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )