[ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Andreas Jung
Running Plone 4.0.5, Zope 2.12, ZODB 3.9.5. Occasionally I receive the following error after starting my instance after the first request. There is no way to recover out other than restarting the instance...then everything is fine. I don't know why this happens from time to time...any clue? Andre

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Hanno Schlichting
On Mon, May 9, 2011 at 1:14 PM, Andreas Jung wrote: > Occasionally I receive the following error after starting my instance > after the first request. > There is no way to recover out other than restarting the > instance...then everything is fine. > I don't know why this happens from time to time.

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > > What does the code of the dgho...UserDataSchemaProvider class look > like? I'm assuming it's similar to the one from plone.app.users that > looks like: > > class UserDataSchemaProvider(object): > implements(IUserData

[ZODB-Dev] Immutable blobs?

2011-05-09 Thread Laurence Rowe
While looking at the Plone versioning code the other day, it struck me that it would be much more efficient to implement file versioning if we could rely on blobs never changing after their first commit, as a copy of the file data would not need to be made proactively in the versioning repository i

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Hanno Schlichting
On Mon, May 9, 2011 at 2:08 PM, Andreas Jung wrote: > Jup - basically a stripped down version of > > http://svn.plone.org/svn/collective/collective.examples.userdata/trunk/collective/examples/userdata/ Hhm, that code has http://svn.plone.org/svn/collective/collective.examples.userdata/trunk/colle

Re: [ZODB-Dev] Immutable blobs?

2011-05-09 Thread Hanno Schlichting
On Mon, May 9, 2011 at 2:26 PM, Laurence Rowe wrote: > While looking at the Plone versioning code the other day, it struck me > that it would be much more efficient to implement file versioning if > we could rely on blobs never changing after their first commit, as a > copy of the file data would

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > On Mon, May 9, 2011 at 2:08 PM, Andreas Jung wrote: >> Jup - basically a stripped down version of >> >> http://svn.plone.org/svn/collective/collective.examples.userdata/trunk/collective/examples/userdata/ > > Hhm, that code

Re: [ZODB-Dev] Immutable blobs?

2011-05-09 Thread Laurence Rowe
On 9 May 2011 13:32, Hanno Schlichting wrote: > On Mon, May 9, 2011 at 2:26 PM, Laurence Rowe wrote: >> While looking at the Plone versioning code the other day, it struck me >> that it would be much more efficient to implement file versioning if >> we could rely on blobs never changing after the

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Hanno Schlichting
On Mon, May 9, 2011 at 2:34 PM, Andreas Jung wrote: > The question is more why this error is happening from time to time after > the startup after the first request - this scares me a bit. I also > encounter a strange issues with PTS from time to time after > startup...but not as frequent as this

Re: [ZODB-Dev] Occasional startup errors in serialize.py/_reconstructor

2011-05-09 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > On Mon, May 9, 2011 at 2:34 PM, Andreas Jung wrote: >> The question is more why this error is happening from time to time after >> the startup after the first request - this scares me a bit. I also >> encounter a strange iss

Re: [ZODB-Dev] Immutable blobs?

2011-05-09 Thread Jim Fulton
On Mon, May 9, 2011 at 8:26 AM, Laurence Rowe wrote: > While looking at the Plone versioning code the other day, it struck me > that it would be much more efficient to implement file versioning if > we could rely on blobs never changing after their first commit, as a > copy of the file data would