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
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
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
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
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
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
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.
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
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
-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
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
+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 -
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
[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:
14 matches
Mail list logo
