[Chris Withers]
> Sorry for the tardy response on this, I read the thread but couldn't
> decode an answer to the question I still have:
>
> - will there be a version of Zope 2.X where I don't have to manually call
> .sync() all the time in order to get invalidations when my script doesn't
> run an
Hi All,
Tim Peters wrote:
Curious: ZODB 3.4's and Zope 2.8's and Zope3's test suites all let this
one slip by. To provoke this, looks like Zope3 had to do
transaction.begin() before it opened any connections. Nothing wrong with
that, it's just unusual -- at least for human-written code .
Sorry f
{Tim]
...
> Curious: ZODB 3.4's and Zope 2.8's and Zope3's test suites all let this
> one slip by. To provoke this, looks like Zope3 had to do
> transaction.begin() before it opened any connections. Nothing wrong with
> that, it's just unusual -- at least for human-written code .
Jim, I think t
[Gary Poster]
> I'm guessing this thread has to do with the recent _synch changes in
> transaction._manager.py. I can't get Zope 3 to [serve pages] without
> the following change to the HEAD (which seems right enough, but this
> is just on the basis of a quick look). Is this right?
It's on the r
On May 5, 2005, at 11:24 PM, Gary Poster wrote:
I can't get Zope 3 to run
Sorry, that should have been "I can't get Zope 3 to serve pages"...
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list
On May 5, 2005, at 8:40 PM, Tim Peters wrote:
...I'd
be happier not finishing this exercise <0.5 wink>, so TM.begin() it
is.
I'm guessing this thread has to do with the recent _synch changes in
transaction._manager.py. I can't get Zope 3 to run without the
following change to the HEAD (which
[Jim Fulton]
>>> ISynchronizer should grow a new method:
>>>
>>> def newTransaction(transaction):
>>> """Hook that is called at the start of a transaction."""
>>>
>>> The TM calls this method with the new transaction.
[Tim Peters]
>> I like this, although I don't know what "start of a
Tim Peters wrote:
[Jim Fulton]
[...]
ISynchronizer should grow a new method:
def newTransaction(transaction):
"""Hook that is called at the start of a transaction."""
The TM calls this method with the new transaction.
I like this, although I don't know what "start of a transaction" mea
[Jim Fulton]
[...]
> ISynchronizer should grow a new method:
>
> def newTransaction(transaction):
> """Hook that is called at the start of a transaction."""
>
> The TM calls this method with the new transaction.
I like this, although I don't know what "start of a transaction" means.
Tim Peters wrote:
[Tim Peters]
...
AFAICT, it would make more sense to move the logic for invoking callbacks
into TransactionManager. Transaction() currently takes an optional
`sychronizers` argument that it never mutates, for which a
TransactionManager always passes its set of registered synchron
[Tim Peters]
> ...
> AFAICT, it would make more sense to move the logic for invoking callbacks
> into TransactionManager. Transaction() currently takes an optional
> `sychronizers` argument that it never mutates, for which a
> TransactionManager always passes its set of registered synchronizers.
>
[Shane Hathaway]
>> Would it be sensible for ZODB to do the equivalent of sync() when users
>> call transaction.begin()? That's what I tend to expect it to do
>> anyway--it takes some effort to remember that it doesn't.
[Jim Fulton]
> Yes, or commit, or abort. That's what Tim and I were pondering
Rajeev J Sebastian wrote:
...
What I also need, is a way to know which objects have changed,
without having to maintain copies: the reason is to show those
changes to the user in my (long-running) PyQt window.
As I mentioned before, ZODB doesn't provide a mechanism for
this. I would like it to fo
> I assume Rajeev doesn't really want to call sync() automatically, because
> that's never what anyone asking that question really wants. What they
> invariably _want_ is for ZEO to process invalidations by magic, and they've
> been calling sync() manually as a way to get that to happen.
What I
Shane Hathaway wrote:
...
Would it be sensible for ZODB to do the equivalent of sync() when users
call transaction.begin()? That's what I tend to expect it to do
anyway--it takes some effort to remember that it doesn't.
Yes, or commit, or abort. That's what Tim and I were pondering
in a part of th
Tim Peters wrote:
> Jim Fulton]
>>We should probably think harder about the semantics of sync. But it
>>implied a transaction boundary -- specifically, an abort. You wouldn't
>>want this to happen automatically.
>
>
> I assume Rajeev doesn't really want to call sync() automatically, because
> tha
[Rajeev J Sebastian]
>>> Is there some means provided by ZODB/Zeo by which I can get notified
>>> about changes to certain objects after performing sync() ?
[Tim Peters]
>> There is not. Object state is loaded by calling its __setstate__()
>> method, and you may be able to hack something out of t
Tim Peters wrote:
[Rajeev J Sebastian]
Is there some means provided by ZODB/Zeo by which I can get notified
about changes to certain objects after performing sync() ?
There is not. Object state is loaded by calling its __setstate__() method,
and you may be able to hack something out of that, but
[Rajeev J Sebastian]
> Is there some means provided by ZODB/Zeo by which I can get notified
> about changes to certain objects after performing sync() ?
There is not. Object state is loaded by calling its __setstate__() method,
and you may be able to hack something out of that, but you would need
19 matches
Mail list logo
