From andrew-sqlos at puzzling.org Wed Oct 6 14:59:05 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Wed, 6 Oct 2004 14:59:05 +0200 Subject: [Z3-sqlos] [PATCH] Use a Transaction per thread, rather than a Connection Message-ID: <20041006125905.GB5420@frobozz> Hi all, I've got a patch I'd like to commit, as it fixes some problems we're having with SQLOS at Canonical. The symptoms we've noticed are: - changes to the database from outside Zope not being visible in Zope, unless we restart Zope. - RelatedJoins -- changes made with addFoo/removeFoo methods generated by RelatedJoins aren't committed, because the SQLObject has no objects to register as dirty in this case. Using an sqlobject.dbconnection.Transaction per thread, rather than a Connection, seems to fix these issues and feels like a better match for the Zope model of "each web request runs in its own thread and its own transaction". Thus, I'd like to commit this patch: --- orig/connection.py +++ mod/connection.py @@ -90,7 +90,7 @@ warnings.warn("Couldn't find a rdb connection by the " "name %s. Please verify your setup." % name, SQLObjectWarning, 3) - connCache[key] = IZopeSQLConnection(newconn()) + connCache[key] = IZopeSQLConnection(newconn()).transaction() return connCache[key] def releaseConnection(name): Although it's a small patch, it's a pretty low-level change, so I'm asking for feedback before just doing it and accidentally breaking someone's code :) -Andrew. From jkocherhans at mac.com Fri Oct 8 21:45:24 2004 From: jkocherhans at mac.com (Joseph Kocherhans) Date: Fri, 8 Oct 2004 13:45:24 -0600 Subject: [Z3-sqlos] Different database connections for different sqlobject containers Message-ID: I've come up with a proof of concept of sorts for having different db connections depending on the container. I'm not familiar enough with zope.app.rdb, etc. to know all the implications of this, but I *am* a little concerned about whether new connections are going to be initialized on every request. Anyhow, if anyone sees anything blatantly bad, or even has any concerns I can explore that would be great. This really just consists of 3 extra lines in SQLObjectContainer's items method. Right now the connection name is dependent on the name of the container. Obviously that won't work in the real world, but I'm just testing for now. If this pans out then I'll add an interface to select the connection TTW. Sidnei suggested I look in ConnectionDescriptor for a way to do this, but I couldn't figure out how to access any contextual information from there. Without the context I don't think there's a way to decide between different connections. Thanks, Joseph def items(self): """Return a sequence-like object containing tuples of the form (name, object) for the objects that appear in the folder. """ for factoryName in self.allowedFactories(): factory = getFactory(factoryName) + from sqlos.connection import ConnectionDescriptor + conn = ConnectionDescriptor(self.__name__) + factory.setConnection(conn) #<- should probably use an adapter here to make sure factory implements setConnection for obj in factory.select(): name = '%s.%s' % (factoryName, obj.id) yield (name, contained(obj, parent=self, name=name)) From sidnei at awkly.org Sat Oct 9 15:36:44 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Sat, 9 Oct 2004 10:36:44 -0300 Subject: [Z3-sqlos] Different database connections for different sqlobject containers In-Reply-To: References: Message-ID: <20041009133644.GG15880@cotia.awkly.org> | Sidnei suggested I look in ConnectionDescriptor for a way to do this, | but I couldn't figure out how to access any contextual information from | there. Without the context I don't think there's a way to decide | between different connections. If you look again, there's this code: try: ut = zapi.getUtility(IConnectionName, context=context) except ComponentLookupError: .... This is where you could hook looking up a different connection. Or even changing the getConnection method below. Or even better: if you add a local connection, and keep the same name, it will pick your local connection in preference to the global one. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher C Code. C Code Run. Run, Code, RUN! PLEASE!!!! From me at carrollkong.com Wed Oct 13 00:00:42 2004 From: me at carrollkong.com (Carroll Kong) Date: Tue, 12 Oct 2004 18:00:42 -0400 Subject: [Z3-sqlos] SQLOS Breaks on ZopeX3-3.0.0C2 Message-ID: <136601c4b0a6$ecdfdbd0$0200a8c0@athena> Since there was a ton of changes from B2 to B3 in regards to the database, I was not too surprised some things would break. I updated to C2, updated psycopgda to the latest rev, updated sqlos to the latest revision. I cannot create any new SQLOS containers. The error message seems pretty vague. I don't see why it would error out at IterSelect? My setup has been pretty static (still using sqlobject 0.6) and it works 100% fine if I use the older psycopgda drivers, older sqlos, and X3-3.0.0-b2. Anyone got it working with C2? Traceback (most recent call last): File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/publisher/publish.py", line 138, in publish result = publication.callObject(request, object) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/publication/zopepublication.p y", line 153, in callObject return mapply(ob, request.getPositionalArguments(), request) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/publisher/publish.py", line 113, in mapply return debug_call(object, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/publisher/publish.py", line 119, in debug_call return object(*args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/pagetemplate/viewpagetemplate file.py", line 76, in __call__ return self.im_func(im_self, *args, **kw) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/pagetemplate/viewpagetemplate file.py", line 45, in __call__ s = self.pt_render(namespace) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/pagetemplate/pagetemplate.py", line 118, in pt_render context, output, tal=not source, strictinsert=0)() File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 165, in __call__ self.interpret(self.program) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 681, in do_useMacro self.interpret(macro) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 377, in do_optTag_tal self.do_optTag(stuff) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 362, in do_optTag return self.no_tag(start, program) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 357, in no_tag self.interpret(program) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 655, in do_defineMacro self.interpret(macro) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 714, in do_defineSlot self.interpret(block) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 706, in do_defineSlot self.interpret(slot) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 655, in do_defineMacro self.interpret(macro) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 208, in interpret handlers[opcode](self, args) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tal/talinterpreter.py", line 427, in do_setLocal_tal self.engine.setLocal(name, self.engine.evaluateValue(expr)) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tales/tales.py", line 698, in evaluate return expression(self) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tales/expressions.py", line 207, in __call__ return self._eval(econtext) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/tales/expressions.py", line 201, in _eval return ob() File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/browser/contents.py ", line 77, in listContentInfo self.addObject() File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/browser/contents.py ", line 236, in addObject adding.action(request['type_name'], new) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/browser/adding.py", line 158, in action self.add(content) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/browser/adding.py", line 72, in add container[name] = content File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/folder/folder.py", line 97, in __setitem__ setitem(self, self.data.__setitem__, name, object) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/contained.py", line 568, in setitem notify(event) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/event/__init__.py", line 23, in notify subscriber(event) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/event/dispatching.py", line 65, in dispatch for ignored in subscribers(event, None): File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/component/__init__.py", line 178, in subscribers return adapters.subscribers(objects, interface) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/interface/adapter.py", line 458, in subscribers return [subscription(*objects) for subscription in subscriptions] File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/event/objectevent.py", line 74, in objectEventNotify adapters = subscribers((event.object, event), None) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/component/__init__.py", line 178, in subscribers return adapters.subscribers(objects, interface) File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/interface/adapter.py", line 458, in subscribers return [subscription(*objects) for subscription in subscriptions] File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/contained.py", line 175, in dispatchToSublocations for sub in subs.sublocations(): File "/usr/local/ZopeX3-3.0.0c2/lib/python/zope/app/container/contained.py", line 206, in sublocations for key in container: File "/usr/local/ZopeX3-3.0.0c2-inst/lib/python/sqlos/container/__init__.py", line 85, in keys for name, obj in self.items(): yield name File "/usr/local/ZopeX3-3.0.0c2-inst/lib/python/sqlos/container/__init__.py", line 102, in items for obj in factory.select(): File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1203, in __iter__ return conn.iterSelect(self) File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 501, in iterSelect select, keepConnection=True)) TypeError: iteration over non-sequence - Carroll Kong From sidnei at awkly.org Wed Oct 13 04:16:30 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Tue, 12 Oct 2004 23:16:30 -0300 Subject: [Z3-sqlos] SQLOS Breaks on ZopeX3-3.0.0C2 In-Reply-To: <136601c4b0a6$ecdfdbd0$0200a8c0@athena> References: <136601c4b0a6$ecdfdbd0$0200a8c0@athena> Message-ID: <20041013021630.GH6836@cotia.awkly.org> On Tue, Oct 12, 2004 at 06:00:42PM -0400, Carroll Kong wrote: | Since there was a ton of changes from B2 to B3 in regards to the database, I | was not too surprised some things would break. I updated to C2, updated | psycopgda to the latest rev, updated sqlos to the latest revision. | | I cannot create any new SQLOS containers. The error message seems pretty | vague. I don't see why it would error out at IterSelect? | | My setup has been pretty static (still using sqlobject 0.6) and it works | 100% fine if I use the older psycopgda drivers, older sqlos, and | X3-3.0.0-b2. | | Anyone got it working with C2? It's an issue with sqlobject. If you get latest version from svn, or add this: def __iter__(self): return self to the Iteration class in dbconnection.py it will probably work. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher CA is definitely like life; When is says "bonus", it means "you are buried" From andrew-sqlos at puzzling.org Wed Oct 20 20:06:00 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Wed, 20 Oct 2004 20:06:00 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos Message-ID: <20041020180600.GD4891@frobozz> Using destroySelf on an SQLOS instance will cause the transaction to fail due to an exception, because sqlos will attempt to call obj.sync() on a now invalid object. Currently, sqlos just intercepts writes to the dirty flag, and adds objects to a list to be synced at the end of the transaction, but never removes from this list (except at the end of a transaction). I see that SQLObject's implementation of destroySelf invokes "self._connection.cache.expire(self.id, self.__class__)" to keep it's object cache consistent... perhaps sqlos should use that cache, rather than manage its own seperate one? I'll try to write a test-case to demonstrate this soon. A nasty workaround is to add this to the SQLOS class: def sync(self): if self._SO_obsolete: return SQLObject.sync(self) But I don't believe this is the correct fix. -Andrew. From sidnei at awkly.org Wed Oct 20 20:20:08 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Wed, 20 Oct 2004 16:20:08 -0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041020180600.GD4891@frobozz> References: <20041020180600.GD4891@frobozz> Message-ID: <20041020182008.GY2927@cotia.awkly.org> On Wed, Oct 20, 2004 at 08:06:00PM +0200, Andrew Bennetts wrote: | Using destroySelf on an SQLOS instance will cause the transaction to fail | due to an exception, because sqlos will attempt to call obj.sync() on a now | invalid object. | | Currently, sqlos just intercepts writes to the dirty flag, and adds objects | to a list to be synced at the end of the transaction, but never removes from | this list (except at the end of a transaction). I see that SQLObject's | implementation of destroySelf invokes | "self._connection.cache.expire(self.id, self.__class__)" to keep it's | object cache consistent... perhaps sqlos should use that cache, rather than | manage its own seperate one? It uses that cache... except it has one per thread *wink*. The list of objects to be synced is not a cache. | I'll try to write a test-case to demonstrate this soon. | | A nasty workaround is to add this to the SQLOS class: | | def sync(self): | if self._SO_obsolete: | return | SQLObject.sync(self) | | But I don't believe this is the correct fix. Sync is called when the transaction commit()'s now. I think that checking for _SO_obsolete there would be fine. Notice that I replaced the handling from inside the transaction manager by firing an event so not to have duplicated code. Unfortunately we didn't had edge cases like this so far, and it would never happen in our application: delete is completely disabled there. It's nice though that the bugs are popping up. I would make the fix myself, but I prefer to wait for your testcase. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher * radix would rather go see glyph than Linus :-) radix: Why? From andrew-sqlos at puzzling.org Wed Oct 20 21:11:26 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Wed, 20 Oct 2004 21:11:26 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041020182008.GY2927@cotia.awkly.org> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> Message-ID: <20041020191126.GF4891@frobozz> On Wed, Oct 20, 2004 at 04:20:08PM -0200, Sidnei da Silva wrote: [...] > | object cache consistent... perhaps sqlos should use that cache, rather than > | manage its own seperate one? > > It uses that cache... except it has one per thread *wink*. The list of > objects to be synced is not a cache. sqlos has one connection per thread, so there's also one SQLObject cache per thread... You're right that a cache isn't necessarily holding the same set of objects as the set that needs to by synced, but at a glance that seems to be true with SQLObject. I'd want to do more than glance to be certain, though :) It feels like unnecessary duplication to have SQLObject and sqlos both tracking objects independently, but on the other hand relying on SQLObject internals like that might be a bit fragile. [...] > I would make the fix myself, but I prefer to wait for your testcase. Coming later tonight, I hope :) -Andrew. From sidnei at awkly.org Wed Oct 20 21:19:11 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Wed, 20 Oct 2004 17:19:11 -0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041020191126.GF4891@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> Message-ID: <20041020191910.GZ2927@cotia.awkly.org> On Wed, Oct 20, 2004 at 09:11:26PM +0200, Andrew Bennetts wrote: | > It uses that cache... except it has one per thread *wink*. The list of | > objects to be synced is not a cache. | | sqlos has one connection per thread, so there's also one SQLObject cache per | thread... Yes, that is correct. And when an ObjectExpired event is received, the object is expired on every cache. def sqlobjectExpiredSubscriber(event): obj = event.object if not ISQLObject.providedBy(obj): return from sqlos.connection import connCache for connection in connCache.values(): connection.cache.expire(obj.id, obj.__class__) .... | You're right that a cache isn't necessarily holding the same set of objects | as the set that needs to by synced, but at a glance that seems to be true | with SQLObject. I'd want to do more than glance to be certain, though :) | | It feels like unnecessary duplication to have SQLObject and sqlos both | tracking objects independently, but on the other hand relying on SQLObject | internals like that might be a bit fragile. I don't think SQLObject tracks modified objects, but correct me if I'm wrong. It's up to the developer to track modifications and call syncUpdate() on the objects if you use lazyUpdates (which we do in sqlos). The current approach seems ok for me. | [...] | > I would make the fix myself, but I prefer to wait for your testcase. | | Coming later tonight, I hope :) Yay! -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Jesus shit. Is there anything twisted doesn't do, or at least doesn't intend to do? tquid: XML. From andrew-sqlos at puzzling.org Sun Oct 24 00:17:28 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Sun, 24 Oct 2004 00:17:28 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041020191910.GZ2927@cotia.awkly.org> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> Message-ID: <20041023221728.GC5033@frobozz> On Wed, Oct 20, 2004 at 05:19:11PM -0200, Sidnei da Silva wrote: > On Wed, Oct 20, 2004 at 09:11:26PM +0200, Andrew Bennetts wrote: [...] > | > | Coming later tonight, I hope :) > > Yay! Ahem: apologies for the delay. Attached is a test case for the bug (I've locally placed it in tests/test_delete.py, but it probably doesn't care). It's somewhat fragile due to using SamplePerson.createTable, so I haven't checked it in yet. And it turns out that current sqlos in SVN has already fixed the bug, because calling syncUpdate on a destroySelf'd object is safe (although that's probably an accident of implementation; Ian Bicking says on sqlobject-discuss that nothing should be relied on after destroySelf is called). The test does fail with the version of sqlos I'm currently developing against. Time to upgrade! :) Ideas on improving the test so that we can commit it and slowly start expanding the test suite are welcome :) On the topic of the tests: ftests/test_transaction.py fails for me with: IOError: [Errno 2] No such file or directory: '/home/andrew/code/sqlos/ftesting.zcml' Is there a file missing from SVN? -Andrew. From andrew-sqlos at puzzling.org Sun Oct 24 00:20:47 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Sun, 24 Oct 2004 00:20:47 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023221728.GC5033@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> Message-ID: <20041023222047.GD5033@frobozz> On Sun, Oct 24, 2004 at 12:17:28AM +0200, Andrew Bennetts wrote: > On Wed, Oct 20, 2004 at 05:19:11PM -0200, Sidnei da Silva wrote: > > On Wed, Oct 20, 2004 at 09:11:26PM +0200, Andrew Bennetts wrote: > [...] > > | > > | Coming later tonight, I hope :) > > > > Yay! > > Ahem: apologies for the delay. ...and here's the actual attachment. -Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_delete.py Type: text/x-python Size: 1513 bytes Desc: not available Url : http://codespeak.net/pipermail/z3-sqlos/attachments/20041024/9b2dba57/attachment.py From sidnei at awkly.org Sun Oct 24 00:27:31 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Sat, 23 Oct 2004 19:27:31 -0300 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023221728.GC5033@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> Message-ID: <20041023222731.GQ19328@cotia.awkly.org> On Sun, Oct 24, 2004 at 12:17:28AM +0200, Andrew Bennetts wrote: | Attached is a test case for the bug (I've locally placed it in | tests/test_delete.py, but it probably doesn't care). | | It's somewhat fragile due to using SamplePerson.createTable, so I haven't | checked it in yet. | | And it turns out that current sqlos in SVN has already fixed the bug, | because calling syncUpdate on a destroySelf'd object is safe (although | that's probably an accident of implementation; Ian Bicking says on | sqlobject-discuss that nothing should be relied on after destroySelf is | called). Right. It's about time to start doing something about delete *wink*. So, my suggestion is to publish a ObjectDeleted event and remove the object from the list of objects registerd with the transaction on a subscriber. | The test does fail with the version of sqlos I'm currently developing | against. Time to upgrade! :) | | Ideas on improving the test so that we can commit it and slowly start | expanding the test suite are welcome :) | | On the topic of the tests: ftests/test_transaction.py fails for me with: | IOError: [Errno 2] No such file or directory: | '/home/andrew/code/sqlos/ftesting.zcml' | | Is there a file missing from SVN? Uhm. Not that I know of. In fact, I can't find anything referencing that file by grepping. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher Do not use the blue keys on this terminal. From sidnei at awkly.org Sun Oct 24 00:33:29 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Sat, 23 Oct 2004 19:33:29 -0300 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023222047.GD5033@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> <20041023222047.GD5033@frobozz> Message-ID: <20041023223329.GR19328@cotia.awkly.org> On Sun, Oct 24, 2004 at 12:20:47AM +0200, Andrew Bennetts wrote: | ...and here's the actual attachment. Looks ok, but I think we should try to handle deletions better by doing what I proposed on the other email. The only change I would make in your test is to use sqlite, and move the createTable to setUp. Other than that it should be fine. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher And Bruce is effectively building BruceIX -- Alan Cox From andrew-sqlos at puzzling.org Sun Oct 24 00:49:53 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Sun, 24 Oct 2004 00:49:53 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023222731.GQ19328@cotia.awkly.org> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> <20041023222731.GQ19328@cotia.awkly.org> Message-ID: <20041023224953.GE5033@frobozz> On Sat, Oct 23, 2004 at 07:27:31PM -0300, Sidnei da Silva wrote: [...] > | > | On the topic of the tests: ftests/test_transaction.py fails for me with: > | IOError: [Errno 2] No such file or directory: > | '/home/andrew/code/sqlos/ftesting.zcml' > | > | Is there a file missing from SVN? > > Uhm. Not that I know of. In fact, I can't find anything referencing > that file by grepping. Hmm. Perhaps I'm not invoking it correctly? I'm doing: python ftests/test_transaction.py (with an appropriate PYTHONPATH set, of course). The reference to the file seems to come from BrowserTestCase inside Zope, which would be why your grep didn't find anything. -Andrew. From andrew-sqlos at puzzling.org Sun Oct 24 00:53:56 2004 From: andrew-sqlos at puzzling.org (Andrew Bennetts) Date: Sun, 24 Oct 2004 00:53:56 +0200 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023223329.GR19328@cotia.awkly.org> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> <20041023222047.GD5033@frobozz> <20041023223329.GR19328@cotia.awkly.org> Message-ID: <20041023225356.GF5033@frobozz> On Sat, Oct 23, 2004 at 07:33:29PM -0300, Sidnei da Silva wrote: > On Sun, Oct 24, 2004 at 12:20:47AM +0200, Andrew Bennetts wrote: > | ...and here's the actual attachment. > > Looks ok, but I think we should try to handle deletions better by > doing what I proposed on the other email. The only change I would make > in your test is to use sqlite, and move the createTable to > setUp. Other than that it should be fine. I looked at using sqlite initially, but I got stuck when I went looking for an sqliteda for Zope 3. All I found was one in the CVS attic on cvs.zope.org! -Andrew. From sidnei at awkly.org Sun Oct 24 00:57:07 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Sat, 23 Oct 2004 19:57:07 -0300 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023224953.GE5033@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> <20041023222731.GQ19328@cotia.awkly.org> <20041023224953.GE5033@frobozz> Message-ID: <20041023225707.GS19328@cotia.awkly.org> On Sun, Oct 24, 2004 at 12:49:53AM +0200, Andrew Bennetts wrote: | Hmm. Perhaps I'm not invoking it correctly? I'm doing: | | python ftests/test_transaction.py | | (with an appropriate PYTHONPATH set, of course). | | The reference to the file seems to come from BrowserTestCase inside Zope, | which would be why your grep didn't find anything. Yeah, something is wrong then. It seems like BrowserTestCase is trying to find the ftesting.zcml in the root of the zope tree. -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher A hacker does for love what others would not do for money. From sidnei at awkly.org Sun Oct 24 00:58:07 2004 From: sidnei at awkly.org (Sidnei da Silva) Date: Sat, 23 Oct 2004 19:58:07 -0300 Subject: [Z3-sqlos] obj.destroySelf() broken in sqlos In-Reply-To: <20041023225356.GF5033@frobozz> References: <20041020180600.GD4891@frobozz> <20041020182008.GY2927@cotia.awkly.org> <20041020191126.GF4891@frobozz> <20041020191910.GZ2927@cotia.awkly.org> <20041023221728.GC5033@frobozz> <20041023222047.GD5033@frobozz> <20041023223329.GR19328@cotia.awkly.org> <20041023225356.GF5033@frobozz> Message-ID: <20041023225807.GT19328@cotia.awkly.org> On Sun, Oct 24, 2004 at 12:53:56AM +0200, Andrew Bennetts wrote: | I looked at using sqlite initially, but I got stuck when I went looking for | an sqliteda for Zope 3. All I found was one in the CVS attic on | cvs.zope.org! Use it the same way as on the docstring of sqlos/transaction/__init__.py -- Sidnei da Silva http://awkly.org - dreamcatching :: making your dreams come true http://www.enfoldsystems.com http://plone.org/about/team#dreamcatcher "Has anyone had problems with the computer accounts?" "Yes, I don't have one." "Okay, you can send mail to one of the tutors ..." -- E. D'Azevedo, Computer Science 372 From jkocherhans at mac.com Mon Oct 25 19:49:22 2004 From: jkocherhans at mac.com (Joseph Kocherhans) Date: Mon, 25 Oct 2004 11:49:22 -0600 Subject: [Z3-sqlos] recent transaction/threading changes and subscribers Message-ID: Ever since the recent transaction changes I've been having problems with zope3 hanging when I add/edit sqlos objects. I think I've tracked the problem down to subscribers, but I wanted to check to see if anyone else is doing something similar. One of my sqlos objects stores dc metadata. I wrote an adapter to store dc metadata in the same table that my sqlobject uses. It simply gets/sets attributes on the sqlobject instance. The CreatorAnnotator and ModifiedAnnotator are being called infinitely though. Is anyone else doing something similar that's working with the HEAD? If I go back to r6801 everything works fine. Thanks, Joseph