[ZODB-Dev] Cleaning up storage interfaces
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. I'm going to remove it on the trunk. If I'm wrong, I can add it back later. 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
[ZODB-Dev] non-transactional undo?
Do we still need to worry about non-transactional undo? It doesn't appear so. ZODB.DB.DB doesn't seem to support it any more. 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] Cleaning up storage interfaces
Hi, 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.) -- 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
[ZODB-Dev] another reason to stop supporting versions
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? I will write the necessary tests to fix the undo bug. 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
[ZODB-Dev] Re: another reason to stop supporting versions
On Apr 24, 2007, at 5:01 PM, Jim Fulton wrote: 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? I will write the necessary tests to fix the undo bug. Oh and I'm pretty sure that transactional undo doesn't handle undo of transactions that touch versions correctly. This runs pretty deep because the storage API implementations don't return enough information to handle versions. The undo method returns a transaction id and a sequence of object ids, but it should return a sequence of object-id/version pairs. 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
[ZODB-Dev] record_iternext API is broken
There's a semi-formal api for iterating over the current records in a storage. It is best explained with an example: next = None while 1: ... oid, tid, data, next = storage.record_iternext (next) ... # do things with oid, tid, and data ... if next is None: ... break Basically, next captures iterator state and you call record_iternext repeatedly until next becomes None. This low-level API was designed to work with ZEO. Maybe some day, we'll build a higher-level API on top of it.The API is broken, because versions aren't returned. In fact, the current FileStorage implementation of this, which tries to ignore versions will fail if there are objects in the FileStorage that are creates in a uncommitted version. We either need to fix this API, or stop supporting versions. (Not that we're really supporting them very well now.) 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
[ZODB-Dev] Re: record_iternext API is broken
I should have noted that this API isn't widely used AFAIK, so it probably wouldn't be that big a deal to change it. Personally, I'd be inclined to change it to return oid, version, and next (or oid and next). Client code could always call load to get the transaction id and data. Thoughts? Jim On Apr 24, 2007, at 7:19 PM, Jim Fulton wrote: There's a semi-formal api for iterating over the current records in a storage. It is best explained with an example: next = None while 1: ... oid, tid, data, next = storage.record_iternext (next) ... # do things with oid, tid, and data ... if next is None: ... break Basically, next captures iterator state and you call record_iternext repeatedly until next becomes None. This low-level API was designed to work with ZEO. Maybe some day, we'll build a higher-level API on top of it.The API is broken, because versions aren't returned. In fact, the current FileStorage implementation of this, which tries to ignore versions will fail if there are objects in the FileStorage that are creates in a uncommitted version. We either need to fix this API, or stop supporting versions. (Not that we're really supporting them very well now.) 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 -- 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] Re: record_iternext API is broken
On Tuesday 24 April 2007 19:23, Jim Fulton wrote: I should have noted that this API isn't widely used AFAIK, so it probably wouldn't be that big a deal to change it. Personally, I'd be inclined to change it to return oid, version, and next (or oid and next). Client code could always call load to get the transaction id and data. Thoughts? I am using it for generation scripts quiet frequently. But if the API becomes better, I am more than willing to change those occurences. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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] Re: another reason to stop supporting versions
I assume you are more interested in seeing if you can get someone to raise a compelling -1 than in hearing a chorus of +1s. But FWIW, +1 in getting rid of versions. It sounds like it would simplify the code significantly, which would be its own feature. Gary ___ 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
-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/ Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLtS7+gerLs4ltQ4RAvn7AJ98Wgm7D/EbA3YS/A/gbJ5bKjbR5QCgtuyv tX4is0ClS1zf1Pa6Oc2RwkE= =I2S0 -END PGP SIGNATURE- ___ 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] Re: Cleaning up storage interfaces
Hi. I am going to be doing an egg release for pgstorage at some point in the next couple of weeks. The current repository is: http://pgstorage.cvs.sourceforge.net/pgstorage/PGStorage/ getSerial is not used in the source. Many thanks. Regards, David 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/ Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLtS7+gerLs4ltQ4RAvn7AJ98Wgm7D/EbA3YS/A/gbJ5bKjbR5QCgtuyv tX4is0ClS1zf1Pa6Oc2RwkE= =I2S0 -END PGP SIGNATURE- ___ 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 ___ 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
+1 for removing versions. they have been considered bad practice for over 3 years. I believe 100% its ok to remove them. alan ___ 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] Cleaning up storage interfaces
I just checked out DirectoryStorage and grepped for getSerial - no occurances. +1 for cleaning up the storage interfaces.. was looking at it over xmas holidays to see if I could implement a sqlite version that was undoless. I didnt get far ;( alan ___ 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
[Alan Runyan] +1 for removing versions. they have been considered bad practice for over 3 years. I believe 100% its ok to remove them. Jim formally announce[d] the intention to deprecate versions in both Zope and ZODB nearly 3 years ago, here: http://mail.zope.org/pipermail/zope3-dev/2004-July/011670.html However, this was predicated upon hav[ing] a [different] way to maintain long-running transactions in Zope. But given that they probably don't work anymore anyway ... ;-) ___ 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
