=== stub [~zen@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stub [~zen@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === stu1 [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad === stu1 is now known as stub === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:46] stub: around [10:46] ? [10:55] morning everyone [10:55] time for a little launchpad love [10:55] lifeless: pong [11:02] daf, rosetta.warthogs.hbd.com seems borked in malone, db errors everywhere [11:04] sabdfl: interesting [11:04] daf: can you see the cause? [11:05] looks like it might be related to some work spiv was doing yesterday [11:05] ProgrammingError: ERROR: current transaction is aborted, commands ignored until end of transaction block [11:05] also, earlier on it was asking me for a username and password, which should i use on that server? [11:05] your username is your email address, assuming there is one for you in the sample data [11:06] the password is also set in the sample data [11:06] let me check... [11:07] looks like you have an email address, but no password [11:07] daf: I've seen that error before - if you get a database exception (such as you violated a key), the connection gets in a weird state and the server needs to be restarted. [11:07] you can use test@canonical.com, password "test" [11:08] daf: thanks [11:10] daf: I don't know if it sqlos, SQLObject or Zope3 yet - I'll be chasing it soon unless someone beats me to it. [11:10] stub: ok, I don't think spiv's up yet, so i'ts probably up for grabs :) [11:11] stub: do you know about the changes spiv made? [11:11] He patched the publish routine didn't he? I don't know the reason he needed to [11:12] I don't think it is related to the ProgrammingError exception though - that is an older bug. [11:12] right, the problem we were seeing was that Zope was seeing stale DB data [11:13] so spiv added an explicit transaction abort [11:13] which apparently fixed the problem [11:13] Was this stale data being retrieved from sqlobject/sqlos? [11:14] not sure [11:14] well, I assume it was [11:14] since I'm pretty sure it wasn't being retrieved from anywhere else [11:15] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2005 is related, but I don't think it's the change in question [11:15] I thought I'd fixed something similar with sqlos (by destroying the connection pool in the publish method, which sounds a similar fix to what spiv needed to do. Maybe my patch has been lost?) [11:15] it's possible [11:15] (that the patch was lost) [11:15] can you check? [11:17] Its still there at the top of beforeTraversal in publication.py [11:19] I'll suck down spiv's changes as soon as I have my new arch archive online to see what he needed to add. [11:19] (I think this was discussed on the launchpad@ list while I was 'away' [11:20] well, the change I'm thinking of was something spiv did yesterday [11:21] actually, forget that [11:21] the change I'm thinking of *was* the patch at #2005 [11:21] and it hasn't been merged to rocketfuel [11:21] Hmm... actually... the ProgrammingError should be impossible if my fix is being invoked, as the connection object should not be reused in different requests. I suspect my fix is not being called :-( [11:21] it's only been applied to the alpha server as a workaround [11:22] I can test that [11:23] where's the fix, exactly? [11:28] (I can't find a method called "publish") [11:29] Just above spiv's patch - lib/canonical/publication.py in beforeTraverse [11:32] hmm, now that I've restarted the server the problem doesn't seem to occur [11:34] ok, now I'm seeing "AttributeError: 'NoneType' object has no attribute 'id' [11:34] " === carlos [~carlos@67.Red-81-32-123.pooles.rima-tde.net] has joined #launchpad [11:40] hrm, things are being weird [11:40] hi carlos [11:40] morning [11:44] daf: so we launch today Rosetta? [11:45] that's the plan [11:46] daf: are you removing things like: [11:46] Join translation team, Start transaltion effort in https://rosetta.ubuntulinux.org/rosetta/search [11:46] gives an error [11:47] to reproduce: I searched for firefox [11:47] lulu: oops [11:47] I'd forgotten about the "advanced" search page [11:47] in advanced search, search results we ahve some dummy data still [11:47] ok - could you sort that before go live? [11:47] yep -- best thing is to disable it for now [11:48] I'll file a bug about implementing it [11:48] daf: perhaps do a check of all pages of functionality you are launching to double check they are all working. [11:50] lulu: right [11:50] lulu: thanks for finding that [11:51] daf: no problem. The about page needs some info - I'm finding some for you... [11:51] daf: have you written the announcement yet? [11:53] daf: we also need rosetta@ubuntulinux.org mailing list set up [11:56] lulu: Will we create accounts into rosetta to anyone that ask for it? [11:56] I'm talking about the alpha [11:56] daf: oh - I see you have rosetta-testers for now - that should do the trick and shows it's still an Alpha. [11:59] daf: Yes - the problem appears after you have violated a database constraint somehow, and stays around until you restart (as restarting the server resets all the database connections). === carlos goes to have breakfast [12:00] carlos: why? do you want to restrict it only to those who are on your testing list? [12:08] spiv: did I mention to you how I hate twisted? === lalo [~lalo@200.102.200.234] has joined #launchpad [12:20] spiv: I need your help for a quick crash course to twisted-proof subprocess handling. [12:21] ddaa: Ok... what do you need to know? [12:21] Or what problem are you having? [12:22] Something totally weird like being unable to fdopen a fd we just created with pipe. [12:22] We decided to use the twisted process handling when the environment has been twistedized. [12:23] So as to avoid all the grief. Twisted assumes that everything going on is using it's process and thread stuff, so we'd rather make it happy3 [12:23] ddaa: Are you passing the right mode to fdopen? [12:24] carlos: Rosetta Alpha - people won't be able to create their own accounts. They will on the Beta when everything is integrated. [12:24] Yes I'm passing the right mode. The problematic code is _working_ it only breaks on production in a twisted env... [12:24] (i.e. os.fdopen(os.pipe()[1] ) will fail, but os.fdopen(os.pipe()[1] , 'w') will work) [12:24] Ok, that's weird. :) [12:24] Where's the code? [12:25] We had too much of that insanity. [12:25] (I've never heard of something like this before) [12:25] It's just a bad idea to do things non-twistedly when twisted has pissed all over the place. [12:26] Well, it's happening with some pretty ugly stuff... ya know the thread-that-reads-on-a-bloking-pipe [12:26] But it would be simply least risky to just do things the twisted way. [12:27] So [12:27] 1. I would like to know what it is in twisted that do plenty of things with signal handlers, thread processing whatever which might cause grief. [12:27] 2. [12:28] Twisted doesn't nothing that should affect threads. [12:28] 2. How can I detect that the environment has been twistized? So I could use twisted process handling in that case, and only in that case. [12:29] (There are some things in Twisted and libraries for Twisted that spawn threads, and manage their own thread pools etc, but that's the extent of it) [12:29] Okay. I take your word for it. [12:30] Apparently, twisted _do_ things to the environment which cause my ugly subprocess handling to die in horrible ways. [12:30] Signal handling happens at reactor.run() time. [12:30] (unless you pass installSignalHandlers=0 to it) [12:30] It installs handlers for: [12:31] our problem occurs within [12:31] twisted/internet/threads.py:37:_putResultInDeferred === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad [12:31] SIGINT (unless there's one already), SIGTERM (always), SIGBREAK (if it exists), and SIGCHLD (ditto) [12:31] is that within reactor.run()? [12:32] Yes, that won't happen until the reactor has already started. [12:32] Oh, actually... [12:32] You could call that at any time. What's the error you get at that line. [12:32] ? [12:32] Nothing at that line [12:33] The error happens much lower in the stack in pyarch process handling code. [12:33] Hmmm.. [12:33] So, if that's the first call to that, that may cause a call to reactor._initThreadPool()... [12:33] When I do things with the evil-blocking-pipe [12:34] What's the last line of the traceback, and the error? [12:34] The pb is that this was the highest visible line in the backtrace lifeless gave me. [12:35] Ok, but what's the lowest? :) [12:35] exceptions.OSError, [Errno 9] Bad file descriptor [12:35] self.readfile = os.fdopen(read_end, 'r', 0) [12:35] The line just before that is: [12:35] read_end, self.write_end = os.pipe() [12:36] Dude, I create a pipe, fdopen it and it barfs! [12:36] I got another backtrace when closing self.readfile [12:37] What's the value of read_end? Perhaps you've run out of fds in that process? [12:37] The reactor does the exact same thing internally for it's "waker". [12:38] do not have the value of read_end... [12:38] (See _UnixWaker in twisted/internet/default.py if you're curious) [12:38] not going there unarmed... [12:39] The problem here _might_ be a fd leak. [12:39] Hmm, although that should raise an OSError at the os.pipe call. [12:39] (I just tested) [12:39] But then it would not explain the error on close. [12:40] So, at this point, I just want to avoid doing things twisted is apparently not prepared for. [12:40] lulu: yes, that's why I was asking because I thought that, Alpha -> only accounts we created, Beta -> everyone [12:40] We already had quite a lot of grief previously (remember at Oxford?) [12:41] And know it breaking prod. [12:41] Well, I honestly don't know of anything in Twisted that interferes with this stuff. [12:41] In fact, Twisted internally relies on doing the exact same thing. [12:41] So, please, just help me to figure out when the environment has been touched by twisted. [12:42] So that the code would use twisted when run in a twisted program, and would use something else in other cases. [12:42] So unless there's some sort of bizarre race in your threads where another thread somehow can be closing the wrong fd, which seems unlikely, I don't know what's causing that problem (I don't know how to reproduce that behaviour even if I'm trying to...) [12:42] Oh, is this code running with my evil hack from Oxford? [12:43] No. Your evil hack was only something for the test suite, and it did not work anyway. [12:43] Ok :) [12:43] i separated the test suite in a twisted part and a pyarch part. [12:44] I do not want to know what's the cause of the problem. [12:44] I just want to use twisted when twisted is being used already. [12:44] See what I mean? [12:44] Yes, I'm just looking that up [12:45] The .running attribute of the reactor can tell you if the reactor is running. [12:45] Once I have that bit, i can dig up the "how to spawn coprocesses" part myself. [12:45] How can I find the reactor? [12:45] from twisted.internet import reactor [12:46] It's a module-global object? [12:46] Yes. [12:46] Thx [12:46] A known design flaw, but convenient. [12:46] Good for my purposes. [12:47] I'll try reproduce the pb and do the twisted things, then. Thanks. [12:48] You're welcome. [12:48] I'd love to know what the problem is, it's very odd :) === lalo [~lalo@200-102-070-253.paemt7003.dsl.brasiltelecom.net.br] has joined #launchpad [01:06] lalo: hey! [01:06] :-( === lalo replaced the motherboard and stuff remains borked [01:08] that leaves two possibilities; either it's my cpu (that would suck, as it's not in warranty), or the hardware is now fine but the libc is borked due to having been compiled on faulty ram [01:09] meanwhile, gossip and lostirc to the rescue [01:12] hi lalo [01:12] good to have you on IRC again [01:13] hello === cprov [~cprov@200.158.100.251] has joined #launchpad [01:22] sqlos questions... [01:22] how do I say 'NOW()' to sqlos [01:22] and how do I say '1 day' to an interval field. [01:22] lifeless: 'NOW' for 'NOW()' [01:22] this is in an assigmnet: [01:22] self._sync.processingapproved=NOW [01:22] ? [01:23] use the string 'NOW' [01:23] oh, the string. === SteveA goes to get lunch === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad [01:27] stub: do you think we should add indexes also for foreign key or with inner joins is enough? (talking about improving the speed) [01:30] lifeless: A quick google suggests 'import sqlobject.sqlbuilder; sqlobject.sqlbuilder.SQLConstant("INTERVAL 1 DAY")' === lalo [~lalo@200-102-070-253.paemt7003.dsl.brasiltelecom.net.br] has joined #launchpad [01:31] spiv , oh ewww. so much for domain & data separation [01:32] There might be a nicer way using mxDateTime's DateTimeDelta or something like that. [01:33] Or even datetime.timedelta(1) [01:34] spiv, stub: hi guys ! [01:34] I seem to remember me and Daf wasting a good half hour in Oxford trying to find what kind of datetime objects sqlo uses [01:34] I think it was mx [01:34] lalo: It has "converters", so in theory it can support multiple kinds. [01:35] Glancing at the source though, it doesn't have any sane support for intervals, though, just absolute dates :/ [01:35] in theory :-) I don't know whether these converters are recent enough to know about the datetime module [01:35] anyway, the reason we were looking was because we wanted to know what objects it would *return* [01:36] lalo: They are. [01:36] But not smart enough to know about datetime.timedetla. [01:36] datetime.timedelta, rather. [01:38] daf: fix, part 1 of 3, done; if we're importing a pofile we already know about (in the db), and the db row has pluralform info, we use that [01:39] part 2 (being done now) is, if we don't have that, try the languages table; part 3 is scream bloody murder if we don't have either [01:41] spiv: so how do I protect a form so only I can set a specific field [01:41] lalo: you need to take care of a fourth case, if the default plural form is not correct for that .po file [01:42] carlos: what kind of care? [01:42] lalo: the error should say that error is that the plural forms used on that file are not the same that the header info [01:42] or the table info so we can fix it easily [01:42] spiv: that interval 1 day thing isn't working [01:43] where table == Language table [01:43] lifeless: Try SQLConstant("INTERVAL '1 DAY'") [01:44] carlos: ouch. That would be... rather involved :-P [01:44] lifeless: I'm currently working on making SQLObject support timedelta, it doesn't seem too hard... [01:44] still not setting it [01:44] Try just the literal string? :/ [01:45] nope [01:46] lifeless: You mean protect a field in a form in zope? I'm not sure, SteveA would know though... [01:47] oooh, found a bug [01:47] well, not web form, the business logic level. Sync.enable() can only be called by me [01:50] oooh, found *another* bug [01:52] lifeless: andrew.bennetts@canonical.com/sqlobject--interval-support--0 should allow you to use datetime.timedelta(1) [01:52] lifeless: Only very lightly tested so far, though. [01:53] and 1 is one second or 1 day ? [01:53] 1 day. [01:53] args for timedelta are days, seconds, microseconds. [01:53] ok, cool [01:53] lalo: I have a couple more interesting errors that happened overnight [01:54] daf: I'm testing the indexs part, I think with 3 indexs will be enough for the import [01:55] carlos: yeah? [01:55] carlos: what are they? [01:55] CREATE INDEX pomsgidsighting_index_inlastrevision ON POMsgIDSighting (pomsgset, pomsgid, inlastrevision); [01:55] CREATE INDEX pomsgidsighting_index_pluralform ON POMsgIDSighting (pomsgset, pluralform); [01:55] CREATE INDEX pomsgset_index_primemsgid ON POMsgSet (potemplate, pofile, primemsgid); [01:55] that's based on postgresql logs [01:55] cool [01:55] do you have any information on how they affect performance? [01:56] daf: I'm doing some tests now [01:56] my first test yesterday save me one minute importing the .pot file [01:56] you gave me a link to some Postgres doc -- can you paste that again? [01:56] daf: good thing all pofiles we have are imported, because the header we're storing in newPOFile was absolutely BS and it would have breaken the exporter [01:57] lifeless: Ooops, give me 2 minutes before testing that :) [01:57] spiv: ah ha [01:57] I'll get a drink then shall I [01:57] lalo: don't we have a but open on that? [01:57] lalo: s/but/bug/ === daf awaits the inevitable Beavis and Butt-head joke [01:57] daf: do we? [01:58] lifeless: Ok, working version mirroring now :) [01:58] I thought we ded [01:58] er, did [01:58] dude, get some caffeine :-P [01:59] http://www.postgresql.org/docs/7.4/static/tutorial-join.html [01:59] lalo: just made some Earl Grey :) [01:59] http://www.postgresql.org/docs/7.4/static/indexes.html [01:59] carlos: a [01:59] grrr [02:00] carlos: thanks [02:00] daf: :-P [02:01] lifeless: My branch lets you set values, but don't expect to get sane values back from reading that field yet :/ [02:01] spiv: aren't you the SQLObject maintainer already? [02:02] ugh. I need to recreate the database each time I want to test this, because zopeless doesn't abort :-/ [02:03] daf: Hah. [02:03] spiv: its still coming across as null. [02:03] omg. [02:03] IntCol('frequency', dbName='syncinterval', default=None), [02:03] # WARNING: syncinterval column type is "interval", not "integer" [02:03] # WARNING: make sure the data is what buildbot expects [02:03] I blame you. [02:03] cool, there is no case 2. The database will always have info (from an old version or from languages table) due to newPOFile() [02:04] lifeless: Oh, d'oh. [02:04] lifeless: Change that to DateTimeCol. [02:04] so either case 1 (the database knows the info) or 3 (it doesn't, scream loud) [02:05] Incidentally, there's been a new upstream release of SQLObject, finally. [02:08] oh, 0.6? [02:08] is that good? :-) [02:08] daf: yeah. [02:08] Although we're basically running it anyway... we're using a recent SVN snapshot. [02:09] But it's a sign that maybe upstream will get around to doing something about my bug reports one day ;) [02:09] since we're basically including the source code in RF, I don't see any pressing need for me to update my packages, then [02:10] spiv: thank thee. [02:12] thou art welcome ;) === carlos goes to have a shower === debonzi [~debonzi@200.158.100.251] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [02:26] stub: I haven't seen any cache deletions happening yet [02:26] but "yet" is about 3 requests [02:26] debonzi, cprov: good work on making the soyuz tables visible [02:26] for malone testing, we need some more sample data of packages, do you guys have any scripts that can populate the test db with a bunch of source packages and versions? [02:29] daf: You lost me. You mean you stuck a debug message in the beforeTraverse and that fix is not being called? [02:29] stub: exactly [02:29] SteveA: ping [02:29] stub: well, it gets the key, but they key is not in the cache [02:30] stub: SteveA said he was having lunch [02:31] daf: Hmm... maybe I'm just using the wrong key then? Can you dump repr(the_connection_cache_mapping) to see what is in it, and more importantly, what the keys are? [02:31] It was working when I nuked the entire dictionary, but that isn't thread safe. [02:31] each request seems to have a different key [02:31] (16386, u'launchpad') [02:32] (32771, u'launchpad') [02:32] etc. [02:32] sabdfl: tks, we still working to have better results til sprint . [02:33] stub: oh, ok, I'm seeing a deletion now [02:33] stub: the error seems to occur when the cache deletions do [02:33] stub: emphasis on "seems" [02:34] I'll try dumping the entire cache mapping [02:34] daf: You will only see a deletion the second time that thread handles a request. I think there are 4 threads by default, so you might not see one until you have loaded 4 or 5 pages. [02:35] cprov: what's the best way for us to get package data in for a couple of thousand packages? [02:35] stub: right, that explains what I've been seeing === stub wonders if z3 can be run in single thread mode like z2's '-t' command line argument === stub reboots again [02:37] wurg [02:37] I think I've got this wireless nutted so it will come up on a reboot :) [02:37] sabdfl: I hope spiv is working on a DEB importer or something related [02:38] sabdfl: a extra component to get information of deb packages and insert automagicly(?) on DB === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [02:40] :) [02:41] stub: so can you approve some of those projectproduct things? [02:41] ok, the cache deletions seem to be working after all [02:42] spiv: spiv is doubting that deleting the adapter is rolling back the transaction [02:42] gaar [02:42] stub: that was supposed to be directed at you === daf is having a bad finger day [02:44] daf: We can explicitly abort the connection at that point if we want (before we nuke it from the cache? spiv's fix might be running to late?) [02:44] lifeless: I can't spell, and I get to approve them?? [02:45] stub: yes. the only thing *I* care about is the project & product name so I can enter them into launchpad. [02:46] that will probably make mark unhappy though, as his beloved shortdesc & description (whats with that?!??) will still need to be fleshed out. [02:46] In the name of the senate and people of rome... *thwack* [02:48] stub: well.. I just /need/ to be able to put them into the system such that I can associate Sync's to products, and then run the syncs., [02:48] Ssh... I'm reading the wiki page... [02:50] stub: ok, sshing. I've emailed mark asking to be able to ignore the desc & shortdesc, but haven't heard back. [02:51] lifeless: So this is where we have to get the project -> product mapping right. I'd assumed bison was part of the GNU project, but you think it is part of its own. Isn't this getting very political? [02:51] stub: I was worried about this happening :( [02:52] stub: not my problem. [02:52] my problem is getting cvs converted to arch. [02:53] Does it really matter if the mapping isn't quite right? We can update them later, surely? [02:53] Not meaning to be a 'boundary drawing arsehole' .. just already about 20 imports behind. [02:53] spiv: given the choice, I'd 100% ignore the projects and products until someone has time to add them and reattach the syncs. [03:01] I'm not sure I can do that. I don't understand what it means when a package has a package or product of "". I also don't know what half of the packages are, and those I do recognize I'm not sure what the project should be :-( [03:03] Does the project name get encoded anywhere permanent in arch (such as the repository name) that we can't fix without rebuilding? [03:07] stub: package comes from the debian package name [03:08] project "" means 'same name as the package' [03:08] product "" means 'same name as the package' [03:08] the project name is used as the arch archive name (project@arch.ubuntu.com) except when I decide otherwise. [03:08] and you cannot fix that: these are one-shot. [03:09] except when there is a very very very good reason, and /no one/ accessing it. [03:09] (accessing it - ever) [03:09] stub: if you can't do it, then I need Mark to be told that: he was trying to delegate it out of being his problem... [03:10] Can a product move between projects, ever? [03:11] I don't know: there are no use cases for these object. [03:11] daf may know as rosetta directly exposes these all the time. [03:12] it is not immutable [03:12] AIUI every aspect of launchpad depended on these objects. [03:12] An example would be mod_python, which after being developed for a few years became an Apache project. [03:12] Where nothing changed except their web server and their logos [03:12] stub: again though: this isn't terribly relevant: we want to know what they should be to perform the imports /today/. [03:12] if someone changes location in the arch world, they just tag across. [03:13] that will be fine:: once we get arch available to the project. [03:13] Cool. So the project looks quite changable - we just need to implement that if it becomes a problem. [03:13] thus my "ignore them all and just do the imports' wish.. [03:14] stub: "ever", sure === lalo cries === stub had also assumed that product names would be changable too [03:15] done recompiling the libc, and stuff remain broken :-( [03:15] ouch [03:15] that leaves the CPU, then? [03:16] stub: I presume its all mutable. this is just hte initialdata load. [03:16] Right. So what is all the fuss about then? [03:16] I'll try downgrading it === stub ducks [03:16] (the libc, not the cpu :-P) [03:18] lifeless: I'll go through and approve the ones I recognize, and reply-all to your email saying if they need approval we really should get a package maintainer or someone with the right knowledge to become involved. [03:19] ah well, firefox 1.0pre runs [03:20] YAY, gaim runs too! :-D my system is fixed === lalo [~lalo@200-102-070-253.paemt7003.dsl.brasiltelecom.net.br] has joined #launchpad [03:21] so it was a software problem all along? [03:22] no - a combo :-) [03:22] the libc was broken because it had been compiled on faulty ram [03:22] I've seen that before [03:22] and you wonder why we say that Gentoo is crack :) [03:23] what if a debian maintainer gets faulty ram? :-) [03:24] at least I got bummered due to my own mistake, not someone else's [03:24] only teasing :) [03:25] ooh, firefox1 knows about gnome and gconf [03:25] it just told me "it's not set as my default browser" :-P I never thought I'd see this message outside windows [03:42] stub: ProgrammingError: ERROR: column sourcepackage.name does not exist [03:42] Yer - I know that one. [03:43] stub: I'd be interested in your thoughts on my latest patches for #2005. [03:43] daf: If you want to test Malone, click on the products link on the front page and use that (or the bug list). Sourcepackage browsing is buggered atm. [03:43] they seem to be working fine [03:44] (the patches) [03:47] spiv: What is the thread issue being discussed in the comments of the SQLObject patch (seems to be about returning a list rather than an iterator from the database) [03:48] I'm not sure, exactly :) [03:48] I think the concern is that SQLObject can have multiple active cursors for a connection alive under some circumstances. [03:49] So if we have lazy iterator in one thread, and another releases the connection, then the lazy iterator will break. [03:49] Hence the listification. [03:49] Perhaps a safer change to SQLObject would've been to wrap the result in iter(...), rather than strip the list(...). [03:49] spiv: So IZopeSQLConnection(newconn()).transaction() registeres the connection with the transaction system, starting the database transaction at the same time? [03:50] I think so :) [03:51] spiv: The connections shouldn't be shared between threads. It might be that the cursor is being reused? [03:51] My basic thinking was that if we use the Transaction object that SQLObject can give us, that's a better fit for the model Zope expects. [03:51] (i.e. a web request gets its own transaction) === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [03:52] So the sqlos lazy updating stuff is now useless? [03:52] (as in unnecessary) === ddaa [~david@nemesis.xlii.org] has joined #launchpad [03:53] I suppose so, except as an optimisation maybe. [03:53] (to avoid unnecessary round trips to the DB) [03:53] stub, spiv - enterprise patterns applies here :) [03:53] APE probably has it already too... [03:54] I don't know too much about the SQLObject level stuff, and haven't dealt with that layer. [03:58] stub: Well, you haven't pointed out any reason why it's obviously stupid, which was my main concern ;) [03:59] I'd be interested to hear what Steve thinks [04:03] spiv: Seems fine actually [04:10] hi stub [04:11] Morning [04:15] is there still a problem with transactions etc? [04:18] Yes - to do with database connection ending up in a 'you are not in a transaction so I'm going to just raise exceptions' state, which shouldn't be happening since we are supposed to be creating a new database connection every transaction (the last time we fixed sqlobject/sqlos). [04:18] Sounds like spiv fixed it though - I havn't tested myself yet. [04:19] Ooh... just got an announcement that SQLObject 0.6 has been released [04:20]