Jeff Rush wrote:
Dmitry Vasiliev wrote:
David Johnson wrote:
I am using the zope database adapter, and on occasion (1/20) the
following code intermittently throws an exception (1/20 times), even
though the connection is connected.
It's a known bug, see
Fred Drake wrote:
(possibly named LLBTree, LOBTree, and OLBTree).
For my half-penny's worth, this is the way I'd like to see it go.
Explicit is better than implicit and all that.
If you need more than 32-bits, you can explicitly use them.
The implicit change to make them all 64-bits which
David Johnson wrote:
In regards to persistence, are we saying this problem occurs when the
connection is an attribute of a persistent object? In our case the
connection resides in a persistent object but is called and used in a
non-persistent one.
It doesn't matter if the 'caller' of the
Good. I think I'm clear. That procedure is exactly what I am following,
except I don't cache queries for this application. My database connection
is a persistent utility. I'll give the global utility a try.
-Original Message-
From: Jeff Rush [mailto:[EMAIL PROTECTED]
Sent: Monday,
On Mon, Apr 17, 2006 at 09:27:07AM -0500, Jeff Rush wrote:
Specifically, we're using the connection in a
non-persistent shopping cart object. Upon initialization the cart object
retrieves the connection from a persistent parent in the context in which
the cart is initialized. In this
Shane Hathaway wrote:
Sidnei da Silva wrote:
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote:
| And I think it's
| very important for the Python code to say what it does, so when I come
| back to a module five months later I'm not staring at MyFactory going
| yeah, but what is it?
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree),
and I'm not the first. I've created a feature
On 4/17/06, Jim Fulton [EMAIL PROTECTED] wrote:
The fact that IIBTrees is so widely used is exatly the reason
I want to use 64-bits for the existing types rather than having to
introduce a new type.
Oops, I was checking in the separated version of 64-bit BTrees while
this was landing in my
Fred Drake wrote:
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree),
and I'm not the first. I've created a feature development branch for
this, and checked in my initial implementation.
I've modified the existing code to use PY_LONG_LONG instead of int for
the key and/or