Tim Peters [EMAIL PROTECTED] writes:
That adds something to the BTree that is bound to an attribute of articleDb,
but still doesn't set _p_changed on articleDb (mutating the BTree does not
mutate the object containing the BTree). So far as the *database* is
concerned, there's still no path
Tim Peters [EMAIL PROTECTED] writes:
[Syver Enstad, wants to switch an attribute of a Persitent subclass
From PersistentList to an IOBTree]
[Tim, guessing]
Quick guess (untested, untried, ...
...
Perhaps shuffling the code around would work, a la:
Persistent.__setstate__(self
I have a Persistent derived class where I want to upgrade from using a
PersistentList to a BTrees.IOBTree.IOBTree.
_articleList is the old Persistent list
_oidsToArticles is the new IOBTree.
def __setstate__(self, state):
articleList = state.get('_articleList')
if
Leonardo Rochael Almeida [EMAIL PROTECTED] writes:
Hi Syver,
Please add this issue to the Collector, including the test (prefereably
without the twisted bits)
Eh, what is the Collector?
___
Zope-Dev maillist - [EMAIL PROTECTED]
Dieter Maurer [EMAIL PROTECTED] writes:
Syver Enstad wrote at 2004-4-21 18:03 +0200:
I have done some experiments with this scheme and I find that
everything gets unloaded when do a connection.close() or
connection.sync() so that performance takes quite a hit.
Maybe, the connection cache
I've used the cache_size paramter to the constructor of the DB to good
effect. Are there any further gotchas for ensuring that the ZODB stays
in memory as much as possible?
___
Zope-Dev maillist - [EMAIL PROTECTED]
Toby Dickenson [EMAIL PROTECTED] writes:
On Thursday 22 April 2004 10:42, Syver Enstad wrote:
I've used the cache_size paramter to the constructor of the DB to good
effect. Are there any further gotchas for ensuring that the ZODB stays
in memory as much as possible?
Memory usage scales
Toby Dickenson [EMAIL PROTECTED] writes:
On Thursday 22 April 2004 11:43, Syver Enstad wrote:
cache_deactivate_after sounds interesting. Since I am running ZODB in
a web server I don't want the data to timeout and disappear from
memory since every object I have should be loaded at all
I am using ZODB 3.2 in a twisted based web application. I have read
that I need to call sync to keep the connection up to date. When
exactly should I call sync? Are there any drawbacks with calling it
immediately after getting a connection, like this:
# for each http request.
connection =
Is it possible to have class methods on ZODB Persistent objects? I am
using 3.2 so that means I am using ExtensionClass.
I guess that moving to 3.3 would mean being able to use class methods?
What is the expected time that the 3.3 release will be ready for
production use?
Andreas Jung [EMAIL PROTECTED] writes:
The simplest solution is to keep the counter as file in the
filesystem. Access to the file
must be synchronized through a lock object (- Python docs). Just a
few lines of Python
code.
It has to work in windows too, so it's a bit more involved but
How does one implement a unique id generator in ZODB. The id's should
be strictyl ascending and be a an int. Would opening a temporary
connection increment a persistent counter and commit do the trick?
___
Zope-Dev maillist - [EMAIL PROTECTED]
I am checking out how to use ZODB with twisted web. I thought that I
would have the DB instance globally accesible and call the open method
to get a connection on each request. I thought that if I use
connection.getTransaction().commit() before sending the response I
will commit on the connection
13 matches
Mail list logo
