Re: [ZODB-Dev] another reason to stop supporting versions
Hi, Am Dienstag, den 24.04.2007, 17:01 -0400 schrieb Jim Fulton: I'm 99.9% sure that version commit and abort are broken in ZODB.DB. The commit methods in CommitVersion, and AbortVersion (and TransactionalUndo) call invalidate on the databse too soon -- before the transaction has committed. This can have a number of bad effects, including causing inconsistent data in connections. An argument for keeping version in the past was that they worked. Well, I think they don't work and I'm not interested in writing the test to fix them. Is anyone else? Nope. However. We deprecated versions in Zope 2 a while ago disabling the ability to add new versions but keeping existing versions alive. We have to tell people what to do before the next update of Zope that includes this change so they do not get locked out of existing data. Unfortunately we have no numbers on how many people use versions. I think I'll raise that question on Zope users and the German users list to get a feeling on how many people react. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] another reason to stop supporting versions
On 4/25/07, Christian Theune [EMAIL PROTECTED] wrote: We have to tell people what to do before the next update of Zope that includes this change so they do not get locked out of existing data. 1. Keep a backup if the ZODB before upgrading. 2. (Optional) Don't use versions. There, done! :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: Cleaning up storage interfaces
On Apr 25, 2007, at 12:10 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Am Dienstag, den 24.04.2007, 13:16 -0400 schrieb Jim Fulton: I'm finally trying to clean up the storage interfaces. I have a question. I'll probably have more later, but I'm going to deal with them one by one rather than trying to save them up. Does anyone know if getSerial is used for anything? I suspect that it is an old name for getTid and would like to remove it in favor of getTid. In particular, it's plumbed through the storage and client servers, but I can't see any evidence that people are using it. Hmm. Looks like it. getTid looks like it's used from ZEO in the verify() method. I didn't find any place where getSerial was used. Zope 3 uses neither (and it probably shouldn't anyway.) DirectoryStorage[1] is probably the major out-of-tree storage implementation to check; PGStorage[2] is likel a distant second in terms of usage: [1] http://dirstorage.sourceforge.net/ [2] http://hathawaymix.org/Software/PGStorage/ I hope very much that Toby and Shane are paying attention to this effort or at least pay attention to the alpha release. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Removing version support
[ Jim Fulton ]: |- We need to first remove the APIs that allow versions to be |created. |- We need to have plans for dealing with databases that contain |version data. For example, database iterators need to skip over |version data, or we need database conversion tools that remove |version data. Supposing that the number of databases that actually *use* versions is smaller than the ones that have stayed away from them... couldn't we just remove versions from the API by default. And, check for vestiges of versions data in databses files. If vestiges were found then the API's would be monkey patched to give some bare minimum version support. If vestiges are *not found*, then these fortunate souls would be running a version-clean (ZODB) version from day one. Nevertheless, I do not know if this suggestion makes any sense, (I never have touched ZODB versions) and if it does, how much work would it imply. Just my 0.5 cents. best regards, Senra - Rodrigo Senra http://rodrigo.senra.nom.br ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Removing version support
[ Jim Fulton ]: |There are undoubtedly databases somewhere that have version data. |They would be pretty rare. Indeed. |I don't know what you mean by the API's would be monkey patched. |What would monkey patch them? What I had in mind was a product that would do these (analysis and monkey patch) things if necessary. After the first run, if no version vestige is detected the product could self-destruct ;o) | Would there be some optional package |that people would install that would do this monkey patching? Yep. |It sounds like we would have to provide an analysis tool, Ops, I thought that detecting the need to support versions would be something simpler, something like looping through the objects and checking types-and-bytes. I'm afraid I had a simplistic view of the problem. |a monkey-patching tool and some pretty complicated documentation. |This feels like a lot more work than other options. Ok, thanks for the feedback. cheers, Senra ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] another reason to stop supporting versions
Jim Fulton wrote at 2007-4-24 17:01 -0400: I'm 99.9% sure that version commit and abort are broken in ZODB.DB. The commit methods in CommitVersion, and AbortVersion (and TransactionalUndo) call invalidate on the databse too soon -- before the transaction has committed. This can have a number of bad effects, including causing inconsistent data in connections. An argument for keeping version in the past was that they worked. Well, I think they don't work and I'm not interested in writing the test to fix them. Is anyone else? The last time I used Versions was about 2 years ago to change the indexes of a catalog without a downtime. Versions was a great help then. With ManagableIndex, I could achieve this today without Versions. But not all indexes have yet the necessary possibility to determine the object values independent from the index id. Thus, I might still miss Version. On this other hand, I currently do not have time to provide the tests and fix the code... -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
