Hi all,
Houston, we've got big a problem !
Here is the traceback in ZEO_EVENTS.log:
"
--
2005-06-02T11:45:21 INFO(0) zrpc-conn:193.49.250.194:37684 zeoLoad() raised
exception: 968647571
Traceback (innermost last):
File /data/ZeoCVS/lib/python/ZEO/zrpc/connection.py, line 234, in
handle_req
[Eric Brun, with a corruption problem]
This is a good place to discuss it, but I can't tell you more here than I
said on zope-dev earlier this morning:
http://mail.zope.org/pipermail/zope-dev/2005-June/024941.html
> ...
> I have tried to do a fsrecover, it removes a transaction.
> ...
> fstest s
I'm working with the ZODB 3.4 beta, and I'm working on getting Catalog
running with it. I noticed that the _Persistence module is not being
built. Is this because ExtensionClass is not included and _Persistence
requires ExtensionClass?
Catalog has a couple of acquisition references that don't work
[Kevin Dangoor]
> I'm working with the ZODB 3.4 beta, and I'm working on getting Catalog
> running with it. I noticed that the _Persistence module is not being
> built. Is this because ExtensionClass is not included and _Persistence
> requires ExtensionClass?
>
> Catalog has a couple of acquisition
Currently, the ZODB cache can only be controlled via the maximal number
of objects. This makes configuration complex as the actual limiting
factor is the amount of available RAM and it is very difficult to
estimate the size of the objects in the cache.
I therefore propose the implementation of cac
Dieter Maurer wrote:
> Currently, the ZODB cache can only be controlled via the maximal number
> of objects. This makes configuration complex as the actual limiting
> factor is the amount of available RAM and it is very difficult to
> estimate the size of the objects in the cache.
>
> I therefore
Shane Hathaway wrote:
Dieter Maurer wrote:
Currently, the ZODB cache can only be controlled via the maximal number
of objects. This makes configuration complex as the actual limiting
factor is the amount of available RAM and it is very difficult to
estimate the size of the objects in the cache.
[Tim Peters]
> ...
> Hmm. _Persistence.c should be removed from ZODB. Zope 2.8 has its own
> copy now, in its lib/python/Persistence/ directory.
Sorry, I lied about that part. Zope 2.8 copies its Persistence directory
from ZODB, so _Persistence.c can't be removed from ZODB yet. Grr --
whic
[oops! sent this to zope-dev by mistake ... but am kinda glad I did]
http://www.zope.org/Collectors/Zope/1800
describes some of the code problems with Zope's current way of mounting
databases. ZODB 3.4 (still) has a Mount.py module, unused and untested by
ZODB. Jim and I were both surprise
On 6/2/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Kevin Dangoor]
> > I'm working with the ZODB 3.4 beta, and I'm working on getting Catalog
> > running with it. I noticed that the _Persistence module is not being
> > built. Is this because ExtensionClass is not included and _Persistence
> > requi
10 matches
Mail list logo