FWIW: this code was checked in just in time for Zope 2.9.0.
A cleaner version is included in 2.9.1 and trunk:
def _getMountedConnection(self, anyjar):
# This creates the DB if it doesn't exist yet and adds it
# to the multidatabase
self._getDB()
# Return a new
Andreas Jung wrote:
the zLOG module will be offically deprecated in Zope 2.10 (removed in
Zope 2.12). New code _must_ use the 'logging' module of Python. And
please help
to replace all outstanding code that uses the zLOG module on the _trunk_
(which is a fun job :-|).
If that is the case then
--On 9. Januar 2006 16:35:31 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote:
If that is the case then I intend to:
1. move the definitions of zope's specific levels (trace and blather)
into a more prominent place (ZODB also defines these levels, but it has
to be an independent package),
[Andreas Jung]
> ZODB defines these levels but I can not see any code in the ZODB package
> that actually uses these levels.
Nevertheless, grep'ing the ZODB source for TRACE and BLATHER will find them.
TRACE is used only in modules under ZEO/zrpc/, and gives extremely verbose
output about bare-met
--On 9. Januar 2006 10:55:21 -0500 Fred Drake <[EMAIL PROTECTED]> wrote:
On 1/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote:
ZODB defines these levels but I can not see any code in the ZODB package
that actually uses these levels.
Nobody should be using the zLOG levels with the logging p
On 9 Jan 2006, at 16:55, Fred Drake wrote:
On 1/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote:
ZODB defines these levels but I can not see any code in the ZODB
package
that actually uses these levels.
Nobody should be using the zLOG levels with the logging package, but
rather use the logging
[Fred Drake]
> Nobody should be using the zLOG levels with the logging package, but
> rather use the logging package levels. So in the end, there's no need
> for Zope to be defining levels at all, only conventions for how the
> levels are used.
The logging package supports defining as many additi
--On 9. Januar 2006 17:06:25 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote:
My point is that the python logging levels are insufficiently fine
grained.
Sufficently enough for me. BLATHER & TRACE can be merged to DEBUG
and PROBLEM to either WARN|ERROR. This should be even enough for Zope.
On 9 Jan 2006, at 17:25, Andreas Jung wrote:
--On 9. Januar 2006 17:06:25 +0100 Florent Guillaume <[EMAIL PROTECTED]>
wrote:
My point is that the python logging levels are insufficiently fine
grained.
Sufficently enough for me.
"Sufficient for me" is not a good reason sorry. If you don't wa
On 9 Jan 2006, at 17:20, Fred Drake wrote:
On 1/9/06, Florent Guillaume <[EMAIL PROTECTED]> wrote:
My point is that the python logging levels are insufficiently fine
grained.
The python logging framework leaves room for numeric levels and
registering equivalent strings, and indeed ZODB and zLOG
--On 9. Januar 2006 17:40:26 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote:
On 9 Jan 2006, at 17:25, Andreas Jung wrote:
--On 9. Januar 2006 17:06:25 +0100 Florent Guillaume <[EMAIL PROTECTED]>
wrote:
My point is that the python logging levels are insufficiently fine
grained.
Sufficent
Hello All,
I am using ZODB as a database for a web-application. I
am having some trouble with the commits, though.
Basically it seems that sometimes transaction.commit()
returns without the commit actually happening. Here is
the compelete senario:
1) user requests some changes to DB via the webro
On 9 Jan 2006, at 21:21, Ammar Hakim wrote:
Sometimes, in the last step the browser still gets the
old data before the change was made. On a refresh,
however, the correct data is obtained. Further, this
problem does not always crop up: it seems that it
occurs if the particual DB operation is ver
13 matches
Mail list logo
