On Fri, 2 Mar 2001 15:33:37 -0500 (EST), "R. David Murray "
[EMAIL PROTECTED] wrote:
On Fri, 2 Mar 2001, Erik Stephens wrote:
Thanks for the response. If I understand you correctly, then as long a
thread does not try to modify an out-of-date object, it will not try to
re-read the most
Is there a hook for before the transaction is committed for objects which
subclass Persistent? I found __inform_commit__ for a "registered" object,
but I can't seem to get that to work as I thought it did. I also tried
subclassing TM like a DA, but to no avail.
TIA,
Tim
Dieter Maurer wrote:
Erik Stephens writes:
I've been working on an implementation of connection pooling for the
MySQLDA. Basically, Zope connections will be pooled by connection
string to reduce the number of unecessary connections to MySQL.
Isn't that trivial with Zope (thanks to
On Mon, 5 Mar 2001 10:56:38 -0500, Tim McLaughlin
[EMAIL PROTECTED] wrote:
Is there a hook for before the transaction is committed for objects which
subclass Persistent?
__getstate__ ?
But why would you want that?
Toby Dickenson
[EMAIL PROTECTED]
I want to be able to raise an event from the property sheets to the product
if a property changes. I'm calling it manage_afterChange. I want it only
to fire once per transaction so that multiple changes are aggregated.
Here's the declaration I have in mind.
manage_afterChange(oldItems,
On Mon, 5 Mar 2001, Tim McLaughlin wrote:
manage_afterChange(oldItems, newItems)
oldItems: dict of id - values before modifications
newItems: dict of new values at end of transaction
This would allow an elegant "reindex" or notification system for objects.
It would also allow for
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention
below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use sub-transaction
commits.
The first
R. David Murray writes:
...
The issue is that parts of the database get updated periodically from an
external source. That is, the author and book tables get replaced
wholesale. But the Book and Author objects are cataloged using
ZCatalog, doing a full text index on a combination of
I am getting some serious Zope lag time (15-20 seconds) for simple HTML
pages when also trying to hit the same port with data requests. The data
requests are = 50 records of text data and SQL Server is optimized (meaning
the querys dont take that long, just the connection to Zope). We are using
John Morton writes:
On Fri, 2 Mar 2001 20:55:40 +0100 (CET) Dieter Maurer [EMAIL PROTECTED]
wrote:
Chris Withers writes:
John Morton wrote:
It doesn't appear to be defined in DT_In.py in 2.2.5, but it is ment
ion in
it's doc string, and is available in the
John D. Heintz wrote:
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention
below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use
In what respect are the _v_* attribs gonna cause problems. My guestimate
was that they disappeared upon transaction commit/abort. I'm also not sure
as to why I would need subtrans since I'm only messing with properties of
the object. To my knowledge, subtrans are only necessary to conserve
Has the problem with the binding of the namespace in pythonscript
been fixed in cvs (if so will it be in b2)? It's a pain to having
to call my pythonscript methods using xyz(_=_).
--RDM
___
Zope-Dev maillist - [EMAIL PROTECTED]
Hi Tim,
I'm glad that worked for you. I think _vote() is the right place to do
what you want.
See my reply to Steve Alexander for my comments on _v_* attributes.
John
Tim McLaughlin wrote:
In what respect are the _v_* attribs gonna cause problems. My guestimate
was that they disappeared
On Mon, 5 Mar 2001, R. David Murray wrote:
Has the problem with the binding of the namespace in pythonscript
been fixed in cvs (if so will it be in b2)? It's a pain to having
to call my pythonscript methods using xyz(_=_).
Hmm. Actually, it's worse than that, since this particular method
I noticed that the most recent hotfix completely
denies access to the getClassAttr, setClassAttr and
delClassAttr from DTML. Is this going to be the
behavior for future Zope versions?
Yes - I think that manipulating actual class objects from
DTML is a Bad Thing.
I know this will break
Hi Steve,
ZPatterns is something that is very high on my must investigate list,
but I am not doing Zope development, but rather ZODB based development.
I'm sure that I can still get lots of good ideas though...
My comment below about _v_* attributes is primarily about not using
functionality
Brian Lloyd wrote:
I noticed that the most recent hotfix completely
denies access to the getClassAttr, setClassAttr and
delClassAttr from DTML. Is this going to be the
behavior for future Zope versions?
Yes - I think that manipulating actual class objects from
DTML is a Bad Thing.
Casey Duncan wrote:
Oh nothing too scary. Mostly I have used it to store a counter to
automatically assign ids to new ZClass instances.
I was really thinking of this as a way to store properties across all
instances of a ZClass. I agree that manipulating objects from DTML is
BAD. My
19 matches
Mail list logo
