Toby Dickenson wrote:
Apart from the most trivial cases, it would allow _v_ attributes to disappear
at random. Its a similar problem to the one that makes it hard to write an
optimiser for python code, and I am unconvinced that this is sane.
Which, unfortunately, then leaves us with the problem
On Thursday 23 October 2003 08:07, Chris Withers wrote:
Toby Dickenson wrote:
Apart from the most trivial cases, it would allow _v_ attributes to
disappear at random. Its a similar problem to the one that makes it hard
to write an optimiser for python code, and I am unconvinced that this is
ChrisW wrote:
Seb Bacon wrote:
Agreed. Are there any situations, apart from the already discussed CMF
skindata, where this currently isn't the case?
I'm a bit puzzled - of what use is a variable which may disappear at
any random time?
For caching things...
Note that caching things
IMO YAGNI. I think the application should tolerate the disappearance of
_v_ vars. I would consider the problem with CMF skins a bug that needs
to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be
reconstructed from data in the skins tool.
Has an issue been filed in
Casey Duncan wrote at 2003-10-15 09:53 -0400:
...
It seems to me that DAs are a bit broken with regard to where they store
their database connection objects. They should register an object with
the transaction that holds the connection so that it can be properly
committed or aborted
Chris Withers wrote at 2003-10-15 12:49 +0100:
Dieter Maurer wrote:
Chris Withers wrote at 2003-10-8 21:22 +0100:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for
completely
disposable data only. The application should expect
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for completely
disposable data only. The application should expect that this values will be
gone at any random time, not just at transaction boundaries.
Agreed. Are there any situations, apart from the already
Dieter Maurer wrote:
Chris Withers wrote at 2003-10-8 21:22 +0100:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for completely
disposable data only. The application should expect that this values will be
gone at any random time, not just at
Toby Dickenson wrote:
Today we have the 'transaction participant' interface. That would be a better
place to hold these things, allowing the DA object itself to be deactivated
if necessary.
What's the 'transaction participant interface' and where can I find otu mroe
about it?
Chris
On Wednesday 15 October 2003 12:47, Chris Withers wrote:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for
completely disposable data only. The application should expect that this
values will be gone at any random time, not just at transaction
Chris Withers wrote:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for
completely disposable data only. The application should expect that
this values will be gone at any random time, not just at transaction
boundaries.
Agreed. Are there any situations,
Seb Bacon wrote:
Agreed. Are there any situations, apart from the already discussed CMF
skindata, where this currently isn't the case?
I'm a bit puzzled - of what use is a variable which may disappear at
any random time?
For caching things...
Chris
Seb Bacon wrote:
Chris Withers wrote:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for
completely disposable data only. The application should expect that
this values will be gone at any random time, not just at transaction
boundaries.
Agreed. Are
On Wednesday 15 October 2003 14:53, Casey Duncan wrote:
Agreed. Are there any situations, apart from the already discussed
CMF skindata, where this currently isn't the case?
I'm a bit puzzled - of what use is a variable which may disappear at
any random time?
It's not exactly random.
Toby Dickenson wrote:
On Wednesday 15 October 2003 14:53, Casey Duncan wrote:
Agreed. Are there any situations, apart from the already discussed
CMF skindata, where this currently isn't the case?
I'm a bit puzzled - of what use is a variable which may disappear at
any random time?
On Wednesday 15 October 2003 15:51, Casey Duncan wrote:
As it is, the hard cache
implementation, although beneficial from a memory management perspective
cause loaded servers to do alot more work because they are constantly
pruning the cache and then reloading objects again immediately
On Friday 10 October 2003 18:34, Dieter Maurer wrote:
Toby Dickenson wrote at 2003-10-10 07:54 +0100:
...
A while ago there was a discussion on zodb-dev about _v_-like attributes
that would be automatically cleared at the end of a transaction. Do we
need something similar that
On Thursday 09 October 2003 14:01, Florent Guillaume wrote:
I agree with this. How do we go about find code that uses the assumption
that _v_ stuff won't change unless it's at a transaction boundary?
Note that we had a problem related to this with a client recently: In
CMF, skin data is
Toby Dickenson wrote:
On Thursday 09 October 2003 14:01, Florent Guillaume wrote:
I agree with this. How do we go about find code that uses the assumption
that _v_ stuff won't change unless it's at a transaction boundary?
Note that we had a problem related to this with a client recently: In
CMF,
Casey Duncan wrote at 2003-10-10 09:26 -0400:
...
IMO YAGNI. I think the application should tolerate the disappearance of
_v_ vars. I would consider the problem with CMF skins a bug that needs
to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be
reconstructed from
On Fri, 2003-10-10 at 14:34, Dieter Maurer wrote:
If such a _v_ attribute is flushed, the next access to the DA
(in the same request) reopens the database. As this is a new
connection, it does not see the changes made by the previous
connection (in the same request).
This can lead to very
I would argue that a better plan would be to only use _v_ vars for completely
disposable data only. The application should expect that this values will be
gone at any random time, not just at transaction boundaries.
I agree with this. How do we go about find code that uses the
Chris Withers wrote at 2003-10-8 21:22 +0100:
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for completely
disposable data only. The application should expect that this values will be
gone at any random time, not just at transaction boundaries.
Casey Duncan wrote:
I would argue that a better plan would be to only use _v_ vars for completely
disposable data only. The application should expect that this values will be
gone at any random time, not just at transaction boundaries.
I agree with this. How do we go about find code that uses
On Friday 26 September 2003 04:37 am, Toby Dickenson wrote:
On Friday 26 September 2003 09:32, Chris Withers wrote:
Toby Dickenson wrote:
On Thursday 25 September 2003 11:51, Chris Withers wrote:
Hmmm, does _p_deactivate() clear the contents of the object's _v_
variables?
Yes
Toby Dickenson wrote:
On Thursday 25 September 2003 11:51, Chris Withers wrote:
Hmmm, does _p_deactivate() clear the contents of the object's _v_
variables?
Yes
Then given your earlier comment that _v_ variables are supposed to last at least
teh length of the request, John's idea of using
On Friday 26 September 2003 09:32, Chris Withers wrote:
Toby Dickenson wrote:
On Thursday 25 September 2003 11:51, Chris Withers wrote:
Hmmm, does _p_deactivate() clear the contents of the object's _v_
variables?
Yes
Then given your earlier comment that _v_ variables are supposed to
def traverseTree(self):
''' Traverse the tree and do something. '''
was_ghost = self._p_changed is None
for ob in self.objectValues():
traverseTree(ob)
# XXX Do something with self here :
self.doSomething()
if was_ghost:self._p_deactivate()
Hmmm, does
On Thursday 25 September 2003 11:51, Chris Withers wrote:
Hmmm, does _p_deactivate() clear the contents of the object's _v_
variables?
Yes
--
Toby Dickenson
___
Zope-Dev maillist - [EMAIL PROTECTED]
29 matches
Mail list logo
