[Zope-Checkins] SVN: Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/ First attempt to fix 'Acquisition problem' when encountering cyclic hierarchies via __parent__ pointers. [hannosc
Log message for revision 76140:
First attempt to fix 'Acquisition problem' when encountering cyclic
hierarchies via __parent__ pointers. [hannosch, nouri]
Changed:
U
Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/_Acquisition.c
U Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/tests.py
-=-
Modified:
Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/_Acquisition.c
===
---
Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/_Acquisition.c
2007-06-01 20:55:13 UTC (rev 76139)
+++
Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/_Acquisition.c
2007-06-01 22:49:26 UTC (rev 76140)
@@ -574,7 +574,16 @@
{
ASSIGN(self-container, newWrapper(self-container, r,
(PyTypeObject*)Wrappertype));
+
+ /* Don't try to get any attributes when the parent object of the
+ parent object is the same as the object itself. */
+ if (WRAPPER(r)-obj==WRAPPER(self)-obj) {
+Py_DECREF(r);
+PyErr_SetObject(PyExc_AttributeError,oname);
+return NULL;
+ }
Py_DECREF(r); /* don't need __parent__ anymore */
+
r=Wrapper_findattr((Wrapper*)self-container,
oname, filter, extra, orig, sob, sco, explicit,
containment);
Modified:
Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/tests.py
===
--- Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/tests.py
2007-06-01 20:55:13 UTC (rev 76139)
+++ Zope/branches/philikon-aq-and-__parent__/lib/python/Acquisition/tests.py
2007-06-01 22:49:26 UTC (rev 76140)
@@ -2010,23 +2010,20 @@
... hello = 'world2'
x = Expl()
- y = Expl2().__of__(x)
+ y = Expl2()
x.__parent__ = y
+ y.__parent__ = x
- x.__parent__.aq_base is y.aq_base
- True
-
x.__parent__.__parent__ is x
True
Acquisition.aq_get(x, 'hello')
'world'
- XXX This causes a segmentation fault, as some tests in Products.Five do
- as well
- Acquisition.aq_get(x, 'hello2')
-
-
+ Acquisition.aq_get(x, 'hello2') #doctest:+ELLIPSIS
+ Traceback (most recent call last):
+ ...
+ AttributeError: hello2
import unittest
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Re: [Bug] ZODB invalidation processing
one very important finding: tryToResolveConflict fails in the resolve function resolve built-in method _p_resolveConflict of BTrees._IOBTree.IOBucket object at 0xb1ab82b4 by raising an exception, when I call it again from the debugger I get. (Pdb) resolved = resolve(old, committed, newstate) *** BTreesConflictError: BTrees conflict error at -1/47/47: Conflicting inserts So that is the real error. -- Gruß Joachim ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
Tres Seaver schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not if the sessions being used are from 'faster' -- it doesn't use
IOBTree. The major application use of that module is in the catalog.
you correct see below:
Try dumping out the contents of the bucket:
for k, v in bucket.items():
print k, type(v)
resolve built-in method _p_resolveConflict of BTrees._IOBTree.IOBucket
object at 0xb1ab82b4
print root._p_jar[p64(0xb1ab82b4)]
*** POSKeyError: ZODB.POSException.POSKeyError instance at 0xa8f9e6cc
with the recepies here http://www.zopelabs.com/cookbook/1114086617
I was able to get the information about the oid, which is passed to
tryToResolveConflict, here is the result
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb2739224}
What does this tell us ?
--
Gruß Joachim
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Tres Seaver schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not if the sessions being used are from 'faster' -- it doesn't use
IOBTree. The major application use of that module is in the catalog.
you correct see below:
Try dumping out the contents of the bucket:
for k, v in bucket.items():
print k, type(v)
resolve built-in method _p_resolveConflict of BTrees._IOBTree.IOBucket
object at 0xb1ab82b4
print root._p_jar[p64(0xb1ab82b4)]
*** POSKeyError: ZODB.POSException.POSKeyError instance at 0xa8f9e6cc
with the recepies here http://www.zopelabs.com/cookbook/1114086617
I was able to get the information about the oid, which is passed to
tryToResolveConflict, here is the result
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb2739224}
What does this tell us ?
That is a real conflict: both transactions have inserted values into
the 'created' date index's '_index' under the same key, which can't be
resolved. Retrying the transaction is the only choice here.
Because DateIndexes convert the indexed value to an integer with
precision of one minute, a date index on 'created' is fairly likely to
generate such conflicts when two parties both create content at the same
time.
Ideally, one would examine the two values being inserted, note that they
were both IITreeSet instances containing one int apiece, and exploit our
knowledge of the application semantics to merge them, removing the
conflict; however, *because* they are IITreeSets, and therefore
separate persistent objects, their state is not available to the
bucket's '_p_resolveConflict', which must therefore lose.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYBDQ+gerLs4ltQ4RAoRNAKCb86Bjhp5fuk7bp9OV2IMUXDKm7ACeO/aH
hVfzx/U0rXsM3iNT2fOl2As=
=egtx
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Thu May 31 12:00:00 2007 UTC to Fri Jun 1 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu May 31 20:51:43 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-May/007814.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu May 31 20:53:13 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-May/007815.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu May 31 20:54:46 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-May/007816.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu May 31 20:56:17 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-May/007817.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu May 31 20:57:48 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-May/007818.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
Tres Seaver schrieb:
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb2739224}
What does this tell us ?
That is a real conflict: both transactions have inserted values into
the 'created' date index's '_index' under the same key, which can't be
resolved. Retrying the transaction is the only choice here.
Because DateIndexes convert the indexed value to an integer with
precision of one minute,
really one minute or do you mean second.
a date index on 'created' is fairly likely to
generate such conflicts when two parties both create content at the same
time.
But then I wonder how a CMF site could ever work, this error shows up
already on my lokal system when to users add something. On our live
system it is killing our portal ?
I would consider this a bug.
Ideally, one would examine the two values being inserted, note that they
were both IITreeSet instances containing one int apiece, and exploit our
knowledge of the application semantics to merge them, removing the
conflict; however, *because* they are IITreeSets, and therefore
separate persistent objects, their state is not available to the
bucket's '_p_resolveConflict', which must therefore lose.
--
Gruß Joachim
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Bug] ZODB invalidation processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joachim Schmitz wrote: some more findings: 1. The conflict error really happens on the Portalcatalog 2. It is a BTreesConflictError: BTrees conflict error at -1/47/47: Conflicting inserts which disguised as ConflictError, through the various try: excepts: 3. It happens on DateIndexes like created and modified. 4. I put for a test: try: resolved = resolve(old, committed, newstate) except: return invalidated into tryToResolveConflict and into the store-method of FileStorage: if serial != cached_tid: rdata = self.tryToResolveConflict(oid, cached_tid,serial, data) if rdata is None: raise POSException.ConflictError(oid=oid, serials=(cached_tid, serial), data=data) elif rdata == invalidated: #new for test old = False # pass # With these hacks I get rid of the conflictErrors. But when I delete the created Items I get: 2007-06-01 13:20:33 ERROR Zope.UnIndex DateIndex: unindex_object tried to retrieve set 1075379718 from index created but couldn't. This should not happen. 2007-06-01 13:20:33 ERROR Zope.UnIndex DateIndex: unindex_object tried to retrieve set 1075379838 from index Date but couldn't. This should not happen. 2007-06-01 13:20:33 ERROR Zope.UnIndex DateIndex: unindex_object tried to retrieve set 1075379719 from index modified but couldn't. This should not happen. So obviously I just fix the symptom with this hack. I think the real cause: lies in these lines: if old: cached_tid = self._get_cached_tid(oid) if cached_tid is None: h = self._read_data_header(old, oid) if h.version: if h.version != version: raise VersionLockError(oid, h.version) pnv = h.pnv cached_tid = h.tid if serial != cached_tid: rdata = self.tryToResolveConflict(oid, cached_tid,serial, data) Which is also supported by the fact, that on our live system which is running on 4 zeo-clients we get this traceback: 2007-06-01T12:38:59 ERROR Zope.SiteErrorLog http://uniben.waeup.org/campus/students/F541700/study_course/create_level Traceback (innermost last): Module Zope2.App.startup, line 173, in zpublisher_exception_hook Module ZPublisher.Publish, line 121, in publish Module Zope2.App.startup, line 240, in commit Module transaction._manager, line 96, in commit Module Products.CPSCompat.PatchZODBTransaction, line 175, in commit Module transaction._transaction, line 436, in _commitResources Module ZODB.Connection, line 665, in tpc_vote Module ZEO.ClientStorage, line 893, in tpc_vote Module ZEO.ClientStorage, line 877, in _check_serials ConflictError: database conflict error (oid 0x8fe833, class BTrees._IOBTree.IOBucket, serial this txn started with 0x036e0418ddcccf55 2007-06-01 11:36:51.984384, serial currently committed 0x036e041a3a33e311 2007-06-01 11:38:13.641254) Any suggestion for a temporary fix would be very welcome, since we get about 6000 conflict errors per day now about 15 % unresolved, and they are really killing our portal. A workaround might be to replace the DateIndexes for 'created' and 'modified' with FieldIndexes: you will see a big jump in the number of keys in the index, but (perhaps) a reduction in conflicts (altheough there will be more bucket splits, which can also cause conflicts). A longer term solution might be to come up with a derived index type which used non-persistent objects (rather than the IITreeSet used by UnIndex) for the set of RIDs stored under each 'minute': you could then inspect the state and do more aggressive conflict resolution than the stock implementation allows (see my other post). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYB4w+gerLs4ltQ4RAhsLAJ9/TR4unlzPMQBY7gfpT6WmQZovywCfQrAF EnkttfiHM7gk1ENrm+ineA4= =oJqE -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Tres Seaver schrieb:
BTrees._IOBTree.IOBTree object at 0xb562fadc
DateIndex at created
Products.ZCatalog.Catalog.Catalog object at 0xb12d622c
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb2739224}
What does this tell us ?
That is a real conflict: both transactions have inserted values into
the 'created' date index's '_index' under the same key, which can't be
resolved. Retrying the transaction is the only choice here.
Because DateIndexes convert the indexed value to an integer with
precision of one minute,
really one minute or do you mean second.
Yes, really one minute.
a date index on 'created' is fairly likely to
generate such conflicts when two parties both create content at the same
time.
But then I wonder how a CMF site could ever work,
You only see conflicts on this index when two people try to insert
content at the same time (i.e., they both start from the same base
transaction ID).
this error shows up
already on my lokal system when to users add something. On our live
system it is killing our portal ?
I would consider this a bug.
Perhaps the QueueCatalog product would help you: that would allow you
to defer updates to the conflict-prone indexes (created, modified,
plus any {ZC,}TextIndexes) for handling by a separate batch process:
http://svn.zope.org/Products.QueueCatalog
It looks as though you may need the trunk version for compatibility with
Zope = 2.9.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYCDR+gerLs4ltQ4RAuI8AJ9eRg+ZIdh3Cdqog3adXQuSIdByHgCeJN0M
8Qb5I8saP9W0eIy+5/OlAmg=
=e5qN
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Bug] ZODB invalidation processing
Any suggestion for a temporary fix would be very welcome, since we get
about 6000 conflict errors per day now about 15 % unresolved, and they
are really killing our portal.
A workaround might be to replace the DateIndexes for 'created' and
'modified' with FieldIndexes: you will see a big jump in the number of
keys in the index, but (perhaps) a reduction in conflicts (altheough
there will be more bucket splits, which can also cause conflicts).
Unfortunately that does not work the FieldIndex also gives an conflict-error
FieldIndex at Date
Products.ZCatalog.Catalog.Catalog object at 0xb250a6ec
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb242989c}
2007-06-01 20:23:41 INFO ZPublisher.Conflict ConflictError at
/uniben/campus/students/A923157/study_course/create_level: database
conflict error (oid 0x36c429, class BTrees._OOBTree.OOBTree, serial this
txn started with 0x036e0590d58661ee 2007-06-01 17:52:50.044906, serial
currently committed 0x036e059346ef95dd 2007-06-01 17:55:16.625597) (1
conflicts (0 unresolved) since startup at Fri Jun 1 19:54:43 2007)
A longer term solution might be to come up with a derived index type
which used non-persistent objects (rather than the IITreeSet used by
UnIndex) for the set of RIDs stored under each 'minute': you could then
inspect the state and do more aggressive conflict resolution than the
stock implementation allows (see my other post).
any other shortterm suggestions.
--
Gruß Joachim
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Any suggestion for a temporary fix would be very welcome, since we get
about 6000 conflict errors per day now about 15 % unresolved, and they
are really killing our portal.
A workaround might be to replace the DateIndexes for 'created' and
'modified' with FieldIndexes: you will see a big jump in the number of
keys in the index, but (perhaps) a reduction in conflicts (altheough
there will be more bucket splits, which can also cause conflicts).
Unfortunately that does not work the FieldIndex also gives an conflict-error
FieldIndex at Date
Products.ZCatalog.Catalog.Catalog object at 0xb250a6ec
CatalogTool at portal_catalog
CPSDefaultSite at uniben
Application at
{'Application': Application at , 'ZGlobals': BTrees._OOBTree.OOBTree
object at 0xb242989c}
2007-06-01 20:23:41 INFO ZPublisher.Conflict ConflictError at
/uniben/campus/students/A923157/study_course/create_level: database
conflict error (oid 0x36c429, class BTrees._OOBTree.OOBTree, serial this
txn started with 0x036e0590d58661ee 2007-06-01 17:52:50.044906, serial
currently committed 0x036e059346ef95dd 2007-06-01 17:55:16.625597) (1
conflicts (0 unresolved) since startup at Fri Jun 1 19:54:43 2007)
A longer term solution might be to come up with a derived index type
which used non-persistent objects (rather than the IITreeSet used by
UnIndex) for the set of RIDs stored under each 'minute': you could then
inspect the state and do more aggressive conflict resolution than the
stock implementation allows (see my other post).
any other shortterm suggestions.
QueueCatalog?
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYGZU+gerLs4ltQ4RAk4BAJ46DKm1vLlygIqee1OxUjSPYF40pwCfSLvy
mS+9UyTtv0OuNWuotzqk5Tg=
=Fevy
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jürgen Kartnaller wrote: We also run into this kind of problems. The only save way to solve it was to serialize our index updates. We do this by using one zope instance which runs only a lovely.remotetask task service. This service contains an indexing task. When indexing is needed we just create a new indexing job which is stored in the job list of the remote task service. That is exactly how QueueCatalog functions: it batches expensive / conflict-prone indexing operations into jobs which are handled later, in a serialized way. This solves two problems : - conflicts - low speed because of complex index value calculations Btw the setup for this application contains 18 zope's each zope running one thread. 17 zope's are used to handle browser requests and one is used to handle the remote tasks (not only indexing tasks). How many of the front-end servers do writes? Or are all your visitors potential writers? Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYOWr+gerLs4ltQ4RAmpyAJwPxdx+ob46RgvasStZwoPWQQTa8gCdG/+t 05J+ocnTgZVOnf7MvLw3oGw= =kyUn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Bug] ZODB invalidation processing
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jürgen Kartnaller wrote: We also run into this kind of problems. The only save way to solve it was to serialize our index updates. We do this by using one zope instance which runs only a lovely.remotetask task service. This service contains an indexing task. When indexing is needed we just create a new indexing job which is stored in the job list of the remote task service. That is exactly how QueueCatalog functions: it batches expensive / conflict-prone indexing operations into jobs which are handled later, in a serialized way. This solves two problems : - conflicts - low speed because of complex index value calculations Btw the setup for this application contains 18 zope's each zope running one thread. 17 zope's are used to handle browser requests and one is used to handle the remote tasks (not only indexing tasks). How many of the front-end servers do writes? Or are all your visitors potential writers? All servers do writes. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYOWr+gerLs4ltQ4RAmpyAJwPxdx+ob46RgvasStZwoPWQQTa8gCdG/+t 05J+ocnTgZVOnf7MvLw3oGw= =kyUn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope] review_state
Hi,
I search a function that return the review_state of an object in Zope.
A function like : object.get('review_state')
row[0] = object.getId()
title = object.Title()
row[1] = title
row[2] = object.getPhysicalPath()
#row[3] = object.get('review_state')
Thanks
Julian
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] review_state
Hi,
In the case of a document proxy managed by CPSWorkflow, I use this:
review_state = proxy.getContentInfo()['review_state']
Is this your case?
If this is not the right way to do it in my context, I'd of course appreciate
your comments :)
Hope it helps,
Jonathan
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de julian
Envoyé : vendredi 1 juin 2007 10:10
À : zope@zope.org
Objet : [Zope] review_state
Hi,
I search a function that return the review_state of an object in Zope.
A function like : object.get('review_state')
row[0] = object.getId()
title = object.Title()
row[1] = title
row[2] = object.getPhysicalPath()
#row[3] = object.get('review_state')
Thanks
Julian
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: review_state
julian, on 2007-06-01:
from Products.CMFCore.utils import getToolByName
from Products.CMFCore.permissions import ManagePortal
query = {'portal_type' : 'Document',
}
for prestataire in self.portal_catalog.searchResults(query):
presta_obj = prestataire.getObject()
wflow = getToolByName(presta_obj, portal_workflow, None)
if wflow is not None:
review_state = wflow.getInfoFor(presta_obj, review_state)
-
So review_state = published or visible...
My problem is resolve :)
Great!
Some notes that may still help:
- I would expect review_state to be in the catalog as well, so instead
of using getObject first you could do:
review_state = prestataire.review_state
- Should you then also want the title or name of the state:
review_state_title = wflow.getTitleForStateOnType(
review_state, 'Document')
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
Do not worry about your difficulties in computers,
I can assure you mine are still greater.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: review_state
Winterflood, Jonathan a écrit :
Hi,
In the case of a document proxy managed by CPSWorkflow, I use this:
review_state = proxy.getContentInfo()['review_state']
Is this your case?
If this is not the right way to do it in my context, I'd of course appreciate
your comments :)
Hope it helps,
Jonathan
Thanks for your help :)
I have fund a good method :p
---
from Products.CMFCore.utils import getToolByName
from Products.CMFCore.permissions import ManagePortal
query = {'portal_type' : 'Document',
}
for prestataire in self.portal_catalog.searchResults(query):
presta_obj = prestataire.getObject()
wflow = getToolByName(presta_obj, portal_workflow, None)
if wflow is not None:
review_state = wflow.getInfoFor(presta_obj, review_state)
-
So review_state = published or visible...
My problem is resolve :)
Julian
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.7 - sporadic service hangup
Hi, we notice two or three times a day some kind of hangup of the zope service. After hangup there is no response requesting urls/manage interface cannot be accessed, too. Restarting the zope service resolves all problems until the next hangup. No errors in zope logs! Seems to work everything fine ... We use Zope 2.7.5-final, python 2.3.5 on Debian, to access LDAP LDAPUserFolder, ZOracleDA for Oracle Connection. I know about problems with ZOracleDA - but not resulting in hangups. What could be the reason? What can I do? Have you tried DeadlockDebugger to see what are your threads doing? I'm not sure if this works with Zope 2.7 -- Maciej Wisniowski ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.7 - sporadic service hangup
Marcel Hartmann wrote: Hi, we notice two or three times a day some kind of hangup of the zope service. After hangup there is no response requesting urls/manage interface cannot be accessed, too. Restarting the zope service resolves all problems until the next hangup. DeadlockDebugger is your friend... No errors in zope logs! Seems to work everything fine ... We use Zope 2.7.5-final, 2.7 is ancient... python 2.3.5 on Debian, to access LDAP LDAPUserFolder, ZOracleDA for Oracle Connection. Problems with either Oracle or your LDAP server could cause these kinds of issues... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [Zope-DB] blobs and dtml-sqlvar
- Original Message - From: e deleflie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 01, 2007 7:58 PM Subject: [Zope-DB] blobs and dtml-sqlvar I'm using MySQLDBA, and I've got a Z SQL Method like this: select * from myTable where someValue=dtml-sqlvar myValue type=string The issue being that 'myValue' is actually a Hex value in a Blob column. The only types possible for dtml-sqlvar seem to be string and int (as far as I can tell). I noticed that when I use 'type=string' the value is always placed in inverted commas (and so MySQL thinks it is a string and rejects it) and when I put 'type=int' the Hex value is rejected by Zope. Is it possible that MySQLDBA can not handle blobs / Hex values at all? I'm confused that dtml-sqlvar only sees 2 types of data. I use ZMySQLDA quite a bit, but I have never used a blob column. According to the documentation the available types are: string, int, float and nb. I had a quick look through the ZMySQLDA source code and saw blob types being defined, but didn't see (during my quick look) how they were being used. So... try the 'nb' type and if that does not work, have a look at the source code and see how the blob types are being used. Not a whole lot of help, but maybe point you in a direction... Good Luck! Jonathan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-DB] blobs and dtml-sqlvar
All, I'm using MySQLDBA, and I've got a Z SQL Method like this: select * from myTable where someValue=dtml-sqlvar myValue type=string The issue being that 'myValue' is actually a Hex value in a Blob column. The only types possible for dtml-sqlvar seem to be string and int (as far as I can tell). I noticed that when I use 'type=string' the value is always placed in inverted commas (and so MySQL thinks it is a string and rejects it) and when I put 'type=int' the Hex value is rejected by Zope. Is it possible that MySQLDBA can not handle blobs / Hex values at all? I'm confused that dtml-sqlvar only sees 2 types of data. Can anyone help? ... Etienne ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
