Andy Dawkins wrote:
> Chris
>
> I the meantime I have changed that method to the following:
>
> def insertReverseIndexEntry(self, entry, documentId):
> """Insert the correct entry into the reverse indexes for future
> unindexing."""
>
> newRow = self._unindex.get(doc
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 mos
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 (t
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, newItems
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 vali
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 suggest
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
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 i
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 sub-t
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
reso
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]
http://lists.zope.or
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 disappeare
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 br
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 B
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. M
20 matches
Mail list logo
