| 00:00.15 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 06:50.14 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 09:26.24 | *** join/#storm mcella (n=michele@ip-179-143.sn2.eutelia.it) |
| 09:48.53 | *** join/#storm harnak (n=harnak@ip-118-90-4-32.xdsl.xnet.co.nz) |
| 09:55.14 | *** join/#storm goschtl (n=goschtl@p5B0BCFA9.dip.t-dialin.net) |
| 12:26.14 | *** join/#storm tarjei (n=tarjeih@mail2.bergfald.no) |
| 12:27.41 | tarjei | howdy, I'm using storm with Twisted on a long running process and today I ran into a problem where Mysql has closed the connection because of inactivity. Do you guys have a suggested way to handle this? |
| 12:43.09 | *** join/#storm niemeyer (n=niemeyer@200-103-245-169.ctame705.dsl.brasiltelecom.net.br) |
| 14:20.41 | jamesh | tarjei: does Storm reconnect for you after you run store.abort()? |
| 14:45.38 | *** join/#storm bigdo2 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 14:56.47 | tarjei | jamesh: ? I connect to the db on startup, and then use the same store throughout the lifetime of the process. |
| 14:57.11 | tarjei | so I never run storm.abort() |
| 14:57.24 | jamesh | tarjei: assuming you are using the latest version, Storm should handle disconnections automatically |
| 14:57.48 | jamesh | tarjei: it doesn't try to reconnect until the current transaction completes though (which happens when you commit() or abort() it) |
| 14:57.59 | tarjei | ah, ok. |
| 14:58.21 | tarjei | I'll try upgrading storm. Running 0.10 now |
| 14:58.22 | jamesh | tarjei: the idea is that you can treat disconnections the same as any other transaction that needs to be retried |
| 14:58.33 | jamesh | (e.g. if you get a deadlock or serialisation error) |
| 14:58.37 | tarjei | ok |
| 14:59.34 | tarjei | and this is new after 0.10 ? |
| 14:59.40 | tarjei | I'll test and report back. |
| 15:00.04 | jamesh | tarjei: new in 0.12 |
| 15:01.08 | jamesh | tarjei: it doesn't reconnect immediately because that can lead to bugs where you might commit the second half of a transaction while having lost the first half |
| 15:01.32 | jamesh | so the disconnect is treated like an abort |
| 15:01.47 | jamesh | I mean an error that requires the transaction to abort |
| 15:27.10 | tarjei | ok |
| 15:27.23 | tarjei | thanks for helping me. |
| 16:05.06 | *** join/#storm jkakar (n=jkakar@c-24-6-86-152.hsd1.ca.comcast.net) |
| 18:41.45 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 19:03.47 | *** join/#storm TimRiker (n=timr@pdpc/supporter/bronze/TimRiker) |
| 19:07.23 | *** join/#storm Brend (n=brendonh@61-225-163-181.dynamic.hinet.net) |
| 19:07.27 | Brend | Hello! |
| 19:08.15 | *** part/#storm TimRiker (n=timr@pdpc/supporter/bronze/TimRiker) |
| 19:08.15 | Brend | So it seems like if the database is changing under Storm's feet (like, from somewhere else), you have to do a rollback before you see the changes |
| 19:08.32 | Brend | Is that right? |
| 19:08.51 | radix | Brend: pretty much, yes. it defaults to isolation level SERIALIZABLE. |
| 19:09.04 | Brend | Can you say that again in English |
| 19:09.08 | radix | Brend: and its caching and identity management depends on that. |
| 19:09.17 | radix | Brend: hmm. I could link you to a document description transaction isolation levels :) |
| 19:09.29 | Brend | Do I want you to do that |
| 19:09.39 | radix | Brend: SERIALIZABLE is basically "no really, I want a reliable sane, consistent database. please." |
| 19:09.57 | Brend | I guess I was hoping for something more like "just add this one line of code and your program will work" |
| 19:10.08 | radix | Brend: the line of code is ".rollback()" probably :) |
| 19:10.19 | radix | or maybe .commit() |
| 19:10.20 | Brend | Before _every action_? |
| 19:10.39 | radix | Brend: it depends where. in web applications, you typically want one transaction per request. |
| 19:11.01 | radix | that way the request has a consistent view of the database for its lifetime. |
| 19:11.09 | Brend | Right let me try that again |
| 19:11.22 | Brend | Before _every logical unit of interaction_? |
| 19:12.02 | radix | Brend: I'd say "any time you want to update your view of the database". I'm not sure what a logical unit of interaction is, and indeed that is certianly more difficult to answer for some apps than others. |
| 19:12.08 | Brend | I mean, most of this code is just selects, which we didn't previously wrap in transactions |
| 19:12.42 | Brend | But if there are various things talking independently to the database, then we should just transact everything? |
| 19:12.45 | radix | Brend: is your app a web app, or something else? |
| 19:12.59 | Brend | There's a web app, and an AMP app, and a cron job, and so on |
| 19:13.04 | radix | Brend: IMO, yes. I use transactions for absolutely everything. |
| 19:13.19 | radix | there are *some* cases where it makes sense to do stuff AUTOCOMMIT or whatever, but they're very uncommon. |
| 19:13.43 | radix | Brend: so, for a web app you'd probably want a transaction per request. For an AMP app you probably want one per command. For a cron job you probably want one for the life time of the job. |
| 19:14.01 | Brend | Alright, that makes sense |
| 19:14.25 | radix | (although if the cron job is doing a *lot* of stuff you may want to break it up into multiple transactions.) |
| 19:14.30 | Brend | Thanks. I just spent like five hours trying to figure out why these things weren't seeing others changes : ) |
| 19:14.40 | Brend | s/others/each others'/ |
| 19:14.46 | radix | yeah. transactionality is fun. |
| 19:15.29 | radix | Brend: don't look too close |
| 19:15.32 | Brend | Hey while I'm here. Any plans to add Axiom-esque convenience functions like findUnique and findOrCreate? |
| 19:15.52 | radix | Brend: hmm. findUnique is basically .one(). |
| 19:16.15 | Brend | Does one() crash if there were two? |
| 19:16.18 | radix | Brend: yes. |
| 19:16.29 | Brend | Then I guess it is |
| 19:16.39 | radix | Brend: findOrCreate is harder with Storm, because Storm doesn't force you to have a particular signature for your items' constructors. |
| 19:16.58 | radix | Axiom does, and it relies on that to construct the object in findOrCreate. |
| 19:18.01 | Brend | Do people really have unlikely signatures for their constructors? |
| 19:20.59 | radix | well, they're not necessarily unlikely. do you mean ones that won't accept columns in the constructor as keyword values? there are probably many examples of that in my own projcet |
| 19:21.44 | radix | Brend: or which might require other, non-column-related parameters that aren't directly mapped to columns. |
| 19:21.54 | Brend | Mine are all just columns ... but that's probably because I'm too used to Axiom |
| 20:04.04 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 20:33.52 | *** join/#storm licorna (n=rvalin@pc-43-102-239-201.cm.vtr.net) |
| 20:35.45 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 22:14.32 | *** join/#storm lmiller (n=lmiller@203.89.215.93) [NETSPLIT VICTIM] |
| 22:14.32 | *** join/#storm SteveA (n=steve@canonical/launchpad/SteveA) [NETSPLIT VICTIM] |
| 22:26.41 | *** join/#storm michelp (n=nmichelp@69-30-72-119.dq1sf.easystreet.com) |
| 22:28.47 | *** join/#storm Fujitsu (n=fujitsu@ubuntu/member/fujitsu) |
| 23:21.10 | *** join/#storm harnak (n=harnak@bilbo.netconcepts.com) |