| 01:16.00 | thumper | jamesh: ping |
| 01:41.17 | jamesh | thumper: pong |
| 01:41.47 | thumper | jamesh: OTP now, but I wanted to talk to you about dates :) |
| 01:42.03 | jamesh | OTP? |
| 01:42.10 | thumper | on the phone |
| 01:42.23 | jamesh | okay |
| 01:42.31 | thumper | datetime values rather than generic dates |
| 01:43.50 | *** join/#storm lifeless (~robertc@122-63-10-108.jetstream.xtra.co.nz) |
| 01:52.08 | thumper | jamesh: we have UtcDateTimeCol fields for our storm classes |
| 01:52.25 | jamesh | yep. I think I wrote the initial version of that ... |
| 01:52.29 | thumper | jamesh: which need a timezone aware datetime |
| 01:52.38 | thumper | however in a query I'm using |
| 01:52.54 | thumper | I have Max(Table.date_col) is returning a timezone unaware date time |
| 01:52.56 | thumper | why? |
| 01:53.17 | thumper | in the db, the column is "timestamp without timezone) |
| 01:53.45 | jamesh | probably because Max() doesn't know that its return value should be the same type as its argument |
| 01:53.48 | thumper | it is making my test a PITA |
| 01:54.01 | jamesh | so is just returning what psycopg gives it |
| 01:54.08 | thumper | hmm... |
| 01:54.28 | thumper | does it sound like a bug? |
| 01:54.36 | thumper | or a feature :) |
| 01:56.09 | jamesh | it is a missing feature. |
| 01:56.33 | jamesh | if the Max() class implemented a variable_factory() method, then it could be made to work |
| 01:57.09 | lifeless | would that break anything? |
| 01:58.49 | jamesh | it shouldn't |
| 02:01.03 | jamesh | basically we'd want to use the same variable_factory as the Max's argument but with allow_none=True |
| 02:01.23 | jamesh | since Max can return NULL even if the column you're aggregating is NOT NULL |
| 02:02.05 | thumper | jamesh: how? |
| 02:02.27 | jamesh | how would you implement variable_factory, or how would MAX return NULL? |
| 02:03.26 | jamesh | if you do "SELECT MAX(column) FROM table" and the table has no rows, then the result will be NULL |
| 02:03.34 | jamesh | whether or not column can be NULL |
| 02:05.30 | thumper | ah |
| 02:05.33 | thumper | fair enough |
| 02:06.24 | jamesh | other cases are if you're doing left or right joins, with no matching rows |
| 02:16.20 | *** join/#storm stub (~stub@ppp-58-11-86-68.revip2.asianet.co.th) |
| 02:16.20 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 02:21.55 | jamesh | thumper: here is a quick and dirty version of what I was talking about: http://paste.ubuntu.com/484290/ |
| 02:23.58 | thumper | jamesh: hmm... interesting |
| 02:24.08 | thumper | now to just get that into trunk :) |
| 02:24.28 | jamesh | iirc jtv ran into a similar problem with another expresion |
| 02:24.33 | jamesh | expression even |
| 02:24.45 | jamesh | hates how his keyboard eats some keypresses |
| 02:24.57 | thumper | jamesh: time for a new laptop? |
| 02:25.15 | jamesh | thumper: it is a Thinkpad USB Keyboard on my desktop |
| 02:25.22 | thumper | ah |
| 02:25.42 | jamesh | other than it sometimes eating a quick repeated keypress, it is great |
| 02:26.37 | jamesh | https://bugs.edge.launchpad.net/storm/+bug/420364 <- this is the bug jtv filed |
| 02:26.38 | _mup_ | Bug #420364: Coalesce doesn't infer result type, breaks with "can't adapt." <tech-debt> <Storm:New> <https://launchpad.net/bugs/420364> |
| 02:26.49 | jamesh | one year ago tomorrow :( |
| 02:44.13 | *** join/#storm jdobrien (~john@184.88.18.24) |
| 02:54.10 | lifeless | sanity check |
| 02:54.15 | lifeless | if I have a result set. |
| 02:54.20 | lifeless | and I call __iter__ on it twice |
| 02:54.26 | lifeless | will it go to the DB both times ? |
| 03:10.21 | jamesh | yes. |
| 03:11.16 | jamesh | the ResultSet object doesn't cache the query result |
| 03:23.31 | lifeless | if I have a result set |
| 03:23.37 | lifeless | which has a field that is a Reference |
| 03:23.51 | lifeless | can I do a bulk change of the a field in that referenced table ? |
| 03:23.56 | lifeless | if so, how do I spell it. |
| 03:24.03 | lifeless | This is the code I'm looking at: |
| 03:24.07 | lifeless | <PROTECTED> |
| 03:24.07 | lifeless | <PROTECTED> |
| 03:24.20 | lifeless | lp/bugs/model/bugs.py +1479 |
| 03:25.22 | lifeless | jamesh: ^ |
| 03:25.56 | jamesh | lifeless: no, but there is a bug open about it. |
| 03:26.11 | lifeless | do you have the number handy? |
| 03:27.46 | jamesh | https://bugs.edge.launchpad.net/storm/+bug/181905 and https://bugs.edge.launchpad.net/storm/+bug/271938 are probably closest |
| 03:27.47 | _mup_ | Bug #181905: IndirectReferenceSet.find().something() produces non-working queries <Storm:New> <https://launchpad.net/bugs/181905> |
| 03:27.48 | _mup_ | Bug #271938: Support for the DELETE FROM x USING y, z statement <tech-debt> <Storm:New> <https://launchpad.net/bugs/271938> |
| 03:28.31 | jamesh | basically it involves adding support for PostgreSQL's and MySQL's non standard join syntaxes for UPDATE and DELETE |
| 03:30.00 | jamesh | if we supported "UPDATE ... FROM ...", ideally you'd be able to do ResultSet.set() on a result that used joins |
| 03:30.17 | lifeless | so, I'd say |
| 03:30.36 | lifeless | self.attachments.set(libraryfile.restricted=private)? But thats a syntax error... |
| 03:31.01 | jamesh | well, you'd need to create a ResultSet for the relevant LibraryFiles |
| 03:31.09 | jamesh | and then do set(restricted=private) on that. |
| 03:31.25 | lifeless | ok, then I'm asking for a new feature I guess |
| 03:31.53 | jamesh | a four argument ReferenceSet() attribute would probably give you that |
| 03:32.00 | lifeless | I have a result set for something that is related and that storm knows the relationships for; I want to poke at the things thus described |
| 03:32.26 | jamesh | ReferenceSet(id, Attachment.bug_id, Attachment.libraryfile_id, LibraryFile.id) |
| 03:33.05 | lifeless | hmm? there is only one LFA for a bug attachment |
| 03:34.57 | jamesh | this would be a Reference set giving you all the LFAs for the bug |
| 03:35.14 | jamesh | joining through the attachments |
| 03:35.49 | lifeless | jamesh: thats unappealing :( |
| 03:35.54 | jamesh | yeah :( |
| 03:36.02 | lifeless | I've filed https://bugs.edge.launchpad.net/storm/+bug/625071 |
| 03:36.04 | _mup_ | Bug #625071: permit updates to fields on the far side of joins <Storm:New> <https://launchpad.net/bugs/625071> |
| 03:36.08 | lifeless | to directly encode my wish. |
| 03:37.41 | jamesh | fair enough. I guess adding PostgreSQL specific compilation for Update is a prerequisite for your request rather than the fix for it. |
| 03:38.02 | lifeless | jamesh: I'm not sure why postgresql specifici stuff is needed |
| 03:38.48 | lifeless | UPDATE LFA SET restricted=True where id in (SELECT attachment.lfa from attachment where bug=54); |
| 03:39.51 | jamesh | lifeless: adding support for the proprietary joins syntax is probably easier than adding code to rewrite queries in terms of a subquery |
| 03:40.06 | jamesh | currently we've got neither. |
| 03:42.17 | lifeless | wearing my user hat, I don't have a preference, because we're using pg |
| 03:42.19 | lifeless | as you know :) |
| 03:42.49 | jamesh | I'd be quite happy to just implement PostgreSQL's syntax |
| 03:43.16 | jamesh | we'll probably do MySQL's too since it is functionally similar (although incompatible) |
| 03:43.28 | jamesh | and raise an error if you try to use the feature with sqlite |
| 03:43.45 | lifeless | I'm not at all sure why the rewrite is harder |
| 03:48.10 | lifeless | is there a precanned caching result set |
| 03:48.29 | lifeless | that is, one which, as long as the criteria are not changed, cache its result ? |
| 03:48.45 | lifeless | if not, is there a bug asking for one ? |
| 03:52.49 | jamesh | I don't think there is an implementation or a bug. |
| 04:53.49 | *** join/#storm jukart (lovely@81.189.156.94) |
| 05:42.01 | *** join/#storm wallyworld (~quassel@110-175-113-247.tpgi.com.au) |
| 06:00.35 | stub | Was FullJoin left out of storm.expr for a reason, or just oversight? |
| 06:27.37 | jamesh | you mean a left+right style outer join? |
| 06:28.06 | jamesh | I don't think it was left out intentionally |
| 07:20.50 | *** join/#storm zmijunkie (~sascha@i53870387.versanet.de) |
| 07:28.38 | stub | Yup - that one |
| 07:43.18 | jamesh | well, patches are welcome. It shouldn't require any additional infrastructure |
| 08:12.01 | *** join/#storm bigjools (~quassel@82-71-93-254.dsl.in-addr.zen.co.uk) |
| 08:12.01 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 08:23.09 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 09:03.47 | *** join/#storm shaunm (~shaunm@74.83.18.167) |
| 09:29.27 | *** join/#storm stub (~stub@ppp-58-11-86-68.revip2.asianet.co.th) |
| 09:29.27 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 09:38.09 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 09:47.45 | *** join/#storm jdobrien (~john@184.88.18.24) |
| 10:52.23 | jamesh | therve: ping? |
| 10:52.48 | therve | jamesh, hi! |
| 10:54.05 | jamesh | therve: hi. We were having some problems with U1 after upgrading to a newer version of Storm. Out of the changes, the most invasive appeared to be https://code.launchpad.net/~therve/storm/mutable-alive-check-553334/+merge/22685, and reverting that seemed to fix the problems. |
| 10:54.25 | therve | crap :/ |
| 10:55.07 | therve | jamesh, is it related to using mutable variable or not? |
| 10:55.26 | jamesh | therve: we don't use any mutable variables, iirc. |
| 10:55.32 | therve | ah |
| 10:55.35 | therve | jamesh, what kind of problems do you see? |
| 10:56.59 | jamesh | therve: the app went unresponsive and had a lot of open db connections (we're using the pgbouncer connection pool, so lots of connections would mean lots of open transactions) |
| 10:57.42 | therve | hum, weird |
| 10:58.10 | *** join/#storm jkakar (~jkakar@53.Red-79-155-137.dynamicIP.rima-tde.net) |
| 10:59.55 | jamesh | hmm, actually I misread the original info: few open transactions |
| 11:00.08 | jamesh | but things ground to a halt. |
| 11:06.14 | therve | so, the worst thing this branch could have done is remove some checkpoints which had to be done |
| 11:07.01 | therve | which basically change the _checkpoint_state value |
| 11:08.14 | therve | jamesh, you're using a custom tree I suppose? the revno differ |
| 11:08.47 | jamesh | therve: yeah. the revnos from the irc log are for our tracking branch. |
| 11:09.15 | therve | jamesh, and you only reverted that particular revision? |
| 11:09.50 | jamesh | yeah. We reverted just the merge of the mutable-alive-check-553334 |
| 11:12.02 | therve | and you don't have any unit tests failing I suppose? |
| 11:12.07 | therve | it would be too easy :) |
| 11:13.04 | jamesh | no. And the way our tree is managed, the unit tests would have had to pass to update the version of Storm we're using |
| 11:13.47 | jamesh | I'm sorry I don't have more information to go on :( |
| 11:16.01 | therve | no worries, sorry to have broken your app :) |
| 11:20.04 | therve | neither landscape or launchpad use a variable number of stores |
| 11:21.01 | therve | so I understand why it may go unnoticed for us |
| 11:21.22 | therve | jamesh, going to lunch, I'll look more after |
| 12:12.35 | *** join/#storm niemeyer (~niemeyer@200-102-194-252.pltce701.dsl.brasiltelecom.net.br) |
| 12:14.04 | *** join/#storm stub (~stub@ppp-58-8-11-198.revip2.asianet.co.th) |
| 12:14.08 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 13:50.38 | *** join/#storm zmijunkie_ (~sascha@i53871B83.versanet.de) |
| 14:17.29 | niemeyer | lifeless: ping |
| 14:23.40 | *** join/#storm fcorrea (~fcorrea@187.3.31.9) |
| 17:55.30 | lifeless | niemeyer: hi |
| 17:55.36 | niemeyer | lifeless: Hey man |
| 17:55.51 | niemeyer | lifeless: Was just wondering about the status quo of looms vs. pipelines |
| 17:56.51 | lifeless | well they havge different use cases |
| 17:57.01 | lifeless | and both of them build out their infrastructure separately from the core |
| 17:57.12 | lifeless | Martin wants to make both of them be thin policy layers |
| 18:06.05 | niemeyer | lifeless: Cool |
| 18:06.25 | niemeyer | lifeless: I guess pipelines is already pretty close to being a policy layer |
| 18:06.36 | niemeyer | lifeless: Since it works mostly with normal branches |
| 18:06.39 | niemeyer | (as I understand it) |
| 18:08.18 | lifeless | right |
| 18:08.28 | lifeless | it does its own funky thing for managing the set of branches |
| 18:08.32 | lifeless | and arranging them |
| 18:43.58 | *** join/#storm jdobrien (~john@24.18.88.184.cfl.res.rr.com) |
| 23:53.36 | *** join/#storm fcorrea (~fcorrea@201-62-110-55-ma.static.vivax.com.br) |