[ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way
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 temporary tables and replication. What the change does, however, is turn a hard error - which stops replication in a way requiring operator intervention - into a recoverable failure. And all this in an application neutral way! Applause here We hope to tackle the main issue (a.k.a. better-not-use-temporary- tables-with-mysql-replication-at-all) in a later installment. Cheers, Stefan P.S.: I am quite excited about the memcached support. Does it just work? I.e. can I run my ZODB in RAM now? ;-) -- Anything that, in happening, causes itself to happen again, happens again. --Douglas Adams ___ 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
Re: [ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way
Stefan H. Holek wrote: I have made two checkins to relstorage 1.1 branch: It's really cool to have another contributor. Thanks! 1.1c1 has already been tagged, so I fixed the change log. [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 temporary tables and replication. What the change does, however, is turn a hard error - which stops replication in a way requiring operator intervention - into a recoverable failure. And all this in an application neutral way! Applause here We hope to tackle the main issue (a.k.a. better-not-use-temporary- tables-with-mysql-replication-at-all) in a later installment. Ok. Conceptually, what we need is a way for each connection to write to a scratch table that no other connection can see. Is there a better way to do that than temporary tables? P.S.: I am quite excited about the memcached support. Does it just work? I.e. can I run my ZODB in RAM now? ;-) I expect the new memcache support to be safe for everyone to use, but we still require the main database to be connected at all times, since memcache provides no ACID properties by itself. We unfortunately can't do obvious things like cache the current transaction ID for an object, since that would break MVCC. What we do cache is: 1. The current tid, given an oid and the transaction ID that is active for the current connection. 2. The pickle given an oid and tid. These should both help read-heavy databases, but might be detrimental for write-heavy databases. My performance test suite, which writes a lot, produced slightly *worse* results with memcache enabled. Shane ___ 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
Re: [ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way
On Thursday 24 July 2008, Shane Hathaway wrote: P.S.: I am quite excited about the memcached support. Does it just work? I.e. can I run my ZODB in RAM now? ;-) I expect the new memcache support to be safe for everyone to use, but we still require the main database to be connected at all times, since memcache provides no ACID properties by itself. We unfortunately can't do obvious things like cache the current transaction ID for an object, since that would break MVCC. What we do cache is: 1. The current tid, given an oid and the transaction ID that is active for the current connection. 2. The pickle given an oid and tid. These should both help read-heavy databases, but might be detrimental for write-heavy databases. My performance test suite, which writes a lot, produced slightly *worse* results with memcache enabled. We should get Brian Aker into this discussion, since is one of the main architects of MySQL and one of the founders of memcached. As Shane knows, I have some access to Brian these days, so we could have an online meeting talking about it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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
Re: [ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way
Stephan Richter wrote: We should get Brian Aker into this discussion, since is one of the main architects of MySQL and one of the founders of memcached. As Shane knows, I have some access to Brian these days, so we could have an online meeting talking about it. Cool. Memcache could do a whole lot more for us if its API had a notion of MVCC. I think that might not be as complicated as it sounds. :-) Shane ___ 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
Re: [ZODB-Dev] RelStorage: Clearing temp_store in replication-friendly way
Stephan Richter wrote: On Thursday 24 July 2008, Shane Hathaway wrote: P.S.: I am quite excited about the memcached support. Does it just work? I.e. can I run my ZODB in RAM now? ;-) I expect the new memcache support to be safe for everyone to use, but we still require the main database to be connected at all times, since memcache provides no ACID properties by itself. We unfortunately can't do obvious things like cache the current transaction ID for an object, since that would break MVCC. What we do cache is: 1. The current tid, given an oid and the transaction ID that is active for the current connection. 2. The pickle given an oid and tid. These should both help read-heavy databases, but might be detrimental for write-heavy databases. My performance test suite, which writes a lot, produced slightly *worse* results with memcache enabled. We should get Brian Aker into this discussion, since is one of the main architects of MySQL and one of the founders of memcached. As Shane knows, I have some access to Brian these days, so we could have an online meeting talking about it. Well, if I can make a suggestion :) From what I understand a new memcache client library was written for MySQL (libmemcache is quite horrible). Python bindings for that library would improve many things, including this :) Wichert. -- Wichert Akkerman[EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
[ZODB-Dev] Re: [Checkins] SVN: zope.component/trunk/src/zope/component/registry.py Correct error in persistance-bbb logic spotted by Jacob Holm
On Thu, Jul 24, 2008 at 1:44 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: Log message for revision 88796: Correct error in persistance-bbb logic spotted by Jacob Holm It seems strange (and a bit frightening) that -- ostensibly -- the tests pass either way the code reads. Is there a missing test here? Changed: U zope.component/trunk/src/zope/component/registry.py -=- Modified: zope.component/trunk/src/zope/component/registry.py === --- zope.component/trunk/src/zope/component/registry.py 2008-07-24 17:32:08 UTC (rev 88795) +++ zope.component/trunk/src/zope/component/registry.py 2008-07-24 17:44:53 UTC (rev 88796) @@ -75,7 +75,7 @@ if provided is None: provided = _getUtilityProvided(component) -if (self._utility_registrations.get((provided, name)[:2]) +if (self._utility_registrations.get((provided, name))[:2] == (component, info)): # already registered return -- Benji York Senior Software Engineer Zope Corporation ___ 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
Re: [ZODB-Dev] indexing
On Wed, 2008-07-23 at 11:41 -0400, [EMAIL PROTECTED] wrote: I've found the ZODB website to be very disorganized an not nearly as helpful as repeated googlings. I have been collecting links and writing some new text for the new ZODB website. But alas there are only so many hours in the day. :-) I am currently running a workshop http://www.oshipworkshop.if.uff.br/ and I will get back onto the ZODB website project after August 1. My apologies. Cheers, Tim -- ** Join the OSHIP project. It is the standards based, open source healthcare application platform in Python. Home page: https://launchpad.net/oship/ Wiki: http://www.openehr.org/wiki/display/dev/Python+developer%27s+page ** signature.asc Description: This is a digitally signed message part ___ 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
