.
Stefan
--
Stefan H. Holek
ste...@epy.co.at
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
FileStorage.
Stefan
--
Stefan H. Holek
ste...@epy.co.at
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
, Claudiu Saftoiu csaft...@gmail.com wrote:
Is there any hook to call *after* the instance attributes get set/loaded
from the database?
True. I guess you'll have to go with Marius' suggestion – ``__setstate__``.
--
Stefan H. Holek
ste...@epy.co.at
to make them
configurable in the relstorage section of zope.conf?
Anybody else has the need for timeouts?
Stefan
[1] http://sendapatch.se/projects/pylibmc/behaviors.html
--
Stefan H. Holek
ste...@epy.co.at
___
For more information about ZODB, see http
On 26.01.2011, at 21:15, Matt Hamilton wrote:
I'm not sure how the current MAX_BUCKET_SIZE values were determined,
but looks like they have been the same since the dawn of time, and I'm
guessing might be due a tune?
Go Matt go! :-)
--
Stefan H. Holek
ste...@epy.co.at
Most projects on svn.zope.org have the policy to perform new work on
the trunk, cutting maintenance branches from it when appropriate.
RelStorage appears to forge ahead on its 1.1 branch, allowing the
trunk to go stale.
What's the policy here? If I wanted to create a branch to work on
This is not a problem of the ZODB or relstorage, but specific to how
MySQL handles a) replication and b) temporary tables.
MySQL employs a log-based replication mechanism. This means the
replication slave replays the commands performed on the master to
keep its copy of the database in
I have made two checkins to relstorage 1.1 branch:
[1] http://svn.zope.org/relstorage/branches/1.1/?rev=88789view=rev
[2] http://svn.zope.org/relstorage/branches/1.1/?rev=88790view=rev
If someone wants to discuss them this is the thread. ;-)
Ad [1]:
This clearly is not the only problem with
H. Holek
[EMAIL PROTECTED]
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
expensive!
--
Stefan H. Holek
[EMAIL PROTECTED]
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
adapter. RelStorage uses
the new_oid table as a kind of sequence. Like any sequence, it is
intentionally non-transactional. Perhaps there would be no ill
effects in switching it to the InnoDB engine.
Which MySQL replication method are you looking into?
--
Stefan H. Holek
[EMAIL PROTECTED
the reference, but it seems that this scheme can
never work without keys (OIDs) being qualified by which master they
originated on. Otherwise one of the mySQLs would need to be
responsible for handing out unique oids. You need an OID
origination namespace for each master.
--
Stefan H. Holek
[EMAIL
Let me rephrase this. Would it be ok to change *all* tables to use the
InnoDB engine (except new_oid)?
Stefan
On 19.05.2008, at 10:55, Stefan H. Holek wrote:
I am playing with database replication (MySQL) and have found the
following caveats:
- don't mix engine types (MyISAM
that all I ever need to
replicate are the InnoDB tables transaction, object_state, and
current_object? All other tables don't seem to be used across
transaction boundaries, but I may be missing something here.
Thanks,
Stefan
--
Stefan H. Holek
[EMAIL PROTECTED
yeas and yes ;-)
Srefan
On 9. Mai 2008, at 18:31, Shane Hathaway wrote:
StorageError: Unable to acquire commit lock
It takes a few moments for that error to appear, doesn't it?
Perhaps the scope of the commit lock in MySQL is the entire
database server rather than just the database,
I try to use two relstorages, roughly following Evan's ZopeLabs recipe
[1]. This is how my zope.conf looks like:
zodb_db main
%import relstorage
relstorage
mysql
db test_zodb
host localhost
/mysql
/relstorage
mount-point /
/zodb_db
BTrees.Length is used in many places to maintain the length of
BTrees. Just the other day it was added to zope.app.container.btree.
While I am happy about the speed improvements, I am concerned about
the fact that BTrees.Length declares itself _p_independent. I'd like
some clarification
https://bugs.launchpad.net/zodb/+bug/124613
Stefan
On 7. Jul 2007, at 19:18, Jim Fulton wrote:
Would you mind creating a launchpad issue to that effect?
--
Anything that, in happening, causes itself to happen again,
happens again. --Douglas Adams
Counting in the ZODB is more or less a no-go. You will get write
conflicts, and your ZODB will grow (too) quickly. That said, you may
want to look at BTrees.Length for a counter with built-in conflict
resolution.
Stefan
On 1. Jun 2007, at 09:47, Kai Diefenbach wrote:
After reading some
You would now use transaction.savepoint(True). Note also that you
don't need to abort a subtransaction or optimistic savepoint, it will
be aborted/committed as part of the full transaction.
Stefan
On 12. Mai 2007, at 19:00, Paul Winkler wrote:
I belatedly realized I have some old test
Do we have a history-less (i.e. no-grow) FileStorage?
Thanks,
Stefan
--
Anything that, in happening, causes something else to happen,
causes something else to happen. --Douglas Adams
___
For more information about ZODB, see the ZODB Wiki:
These errors are *also* due to
ZODB.tests.testZODB.checkResetCachesAPI. The cache reset appears to
leave the Application object and/or transactions in a borked state.
All is well when I suppress checkResetCachesAPI:
$ python2.4 test.py -q -m '!^(ZEO|zope[.]app[.])' -t '!
Hi all,
The ExtFile product I maintain keeps its payload on the filesystem.
All operations are performed using temporary files which are then
saved or deleted on transaction commit or abort respectively.
To this end an ExtFile provides _finish and _abort methods which are
hooked up to a
23 matches
Mail list logo
