| 00:20.30 | jamesh | thumper: yeah |
| 00:20.52 | thumper | jamesh: I'm messing with a relatively complex query i'm trying to stormify |
| 00:21.08 | thumper | wondering how much I have to sprinkle the code with SQL |
| 00:22.48 | thumper | jamesh: http://pastebin.ubuntu.com/579953/ |
| 00:22.57 | jamesh | looks |
| 00:23.04 | thumper | jamesh: that query runs correctly against our staging database |
| 00:23.32 | thumper | obviously the hard coded values are just for the test |
| 00:23.55 | thumper | actually the extra left joins are a hang over from other order by criteria in other tests |
| 00:24.20 | jamesh | we don't have anything to generate the "WITH RECURSIVE ..." clause, so you'll probably have to specify that with an SQL() string. |
| 00:24.24 | thumper | is there a way to print out the generated SQL of a statement for a test |
| 00:24.40 | jamesh | Specification.id.is_in(SQL("WITH RECURSIVE ...")) |
| 00:24.48 | thumper | I've got store.of(self).with_(SQL(...)) |
| 00:25.14 | thumper | this one though needs the subselect |
| 00:25.24 | thumper | I've pretty much got that one |
| 00:25.29 | thumper | the left joins |
| 00:25.34 | thumper | I'm sure I've done them before |
| 00:25.47 | thumper | somewhere |
| 00:26.25 | jamesh | as far as testing generated SQL, if you've got a ResultSet object, you could try using its get_select() method, and then try compiling the resulting object |
| 00:26.55 | thumper | compiling? |
| 00:27.04 | thumper | get_select gives me a what? |
| 00:27.37 | jamesh | ResultSet.get_select(columns, ...) gives you a Select object representing the ResultSet's query returning the given columns. |
| 00:28.31 | jamesh | passing that to sql.expr.compile() should give you a string |
| 00:28.35 | *** join/#storm lifeless (~robertc@122-63-10-108.jetstream.xtra.co.nz) |
| 00:28.38 | lifeless | ola |
| 00:28.45 | thumper | hola |
| 00:28.50 | thumper | :) |
| 00:29.07 | thumper | sql.expr live where? storm? |
| 00:29.07 | jamesh | thumper: is this with_() method something from Launchpad's branch of Storm? |
| 00:29.12 | jamesh | bah. |
| 00:29.16 | jamesh | storm.expr.compile |
| 00:29.27 | thumper | jamesh: I think it is in trunk now |
| 00:29.27 | jamesh | too early |
| 00:29.30 | thumper | just not released |
| 00:29.43 | thumper | and yes, in LP's storm |
| 00:30.27 | jamesh | it isn't in Storm's trunk |
| 00:30.56 | thumper | um... |
| 00:31.01 | thumper | ok |
| 00:31.05 | lifeless | its proposed for merging |
| 00:31.05 | thumper | not sure where it came from then |
| 00:31.07 | jamesh | I can see lifeless's merge proposal though |
| 00:31.17 | lifeless | https://code.launchpad.net/~lifeless/storm/with/+merge/52630 |
| 00:33.43 | jamesh | thumper: anyway, the simplest way I'd structure that query with Storm would be to blat the whole "WITH RECURSIVE ..." query in an SQL() string |
| 00:33.55 | thumper | jamesh: yeah, that's what I have now |
| 00:33.58 | thumper | thanks |
| 00:38.27 | lifeless | thumper: what does it look like ? |
| 00:38.35 | thumper | what does what look like? |
| 00:38.37 | thumper | the query? |
| 00:38.43 | lifeless | yeah, the python |
| 00:38.44 | thumper | <PROTECTED> |
| 00:38.49 | thumper | ah... |
| 00:38.53 | thumper | still working on the python |
| 00:39.02 | thumper | well... |
| 00:39.07 | thumper | actually working on the damn vocabulary |
| 00:39.16 | lifeless | so whats the not in for ? |
| 00:41.51 | thumper | lifeless: to prevent dependency loops |
| 00:43.11 | lifeless | thumper: but whats the use case you're querying for |
| 00:43.15 | lifeless | btw |
| 00:43.16 | lifeless | http://pastebin.ubuntu.com/579954/ |
| 00:43.19 | lifeless | should be more efficient |
| 00:43.46 | thumper | https://bugs.launchpad.net/launchpad/+bug/707111 |
| 00:43.47 | _mup_ | Bug #707111: Blueprint dependency picker doesn't allow searching outside the target <escalated> <linaro> <Launchpad itself:In Progress by thumper> < https://launchpad.net/bugs/707111 > |
| 00:43.49 | thumper | that's the guts of it |
| 00:44.27 | lifeless | so 'do not show things this specification is a dependency for when selecting new dependencies' ? |
| 00:44.54 | thumper | and don't show any specification that this specification already blocks when selecting new deps |
| 00:45.07 | lifeless | thumper: same thing |
| 00:45.09 | thumper | I realised that the query I showed has the wrong one |
| 00:45.17 | thumper | lifeless: yes |
| 00:45.23 | thumper | sorry, misread your statement |
| 00:45.29 | lifeless | thumper: ok, cool. Uhm, a UI consideration : folk may be confused if they cannot select things that they know exist |
| 00:45.44 | lifeless | thumper: so it might make sense to find anything and show it differently if its not usable |
| 00:45.53 | lifeless | s/select/search for/ |
| 00:46.00 | thumper | lifeless: hard to do in our picker infrastructure |
| 00:46.04 | lifeless | yeah :( |
| 00:46.10 | lifeless | so much stuff is hard in our infrastructure |
| 00:46.16 | thumper | lifeless: also... this is how it behaves now |
| 00:46.22 | thumper | lifeless: but with more restrictions |
| 00:46.23 | lifeless | thumper: fair enough |
| 00:46.33 | lifeless | thumper: anyhow - let me know if I can help |
| 00:46.35 | thumper | lifeless: back to #launhpad-dev |
| 01:12.34 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 01:21.03 | thumper | jamesh: does storm have an ILIKE equivalent? |
| 01:21.23 | thumper | jamesh: nm |
| 03:20.07 | *** join/#storm sidnei (~sidnei@201-66-163-145.cslce701.dsl.brasiltelecom.net.br) |
| 05:37.09 | *** join/#storm jamesh (~james@canonical/launchpad/jamesh) |
| 05:59.12 | *** join/#storm jamesh (~james@canonical/launchpad/jamesh) |
| 06:03.38 | *** join/#storm fcorrea (~fcorrea@201-62-110-81-ma.static.vivax.com.br) |
| 06:03.38 | *** join/#storm medberry (~medberry@c-75-71-81-190.hsd1.co.comcast.net) |
| 06:05.03 | *** join/#storm wallyworld__ (~quassel@27-33-46-253.static.tpgi.com.au) |
| 06:52.04 | *** join/#storm stub (~stub@125.24.101.96.adsl.dynamic.totbb.net) |
| 06:52.04 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 06:54.40 | *** join/#storm stub (~stub@125.24.101.96.adsl.dynamic.totbb.net) |
| 06:54.40 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 07:39.54 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 08:20.23 | *** join/#storm danilos (~danilo@cable-178-148-38-107.dynamic.sbb.rs) |
| 08:20.23 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 09:03.46 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 09:29.38 | *** join/#storm zmijunkie (~sascha@89.244.144.84) |
| 10:53.54 | *** join/#storm esteve (~quassel@cli-5b7ee22f.bcn.adamo.es) |
| 12:15.04 | *** join/#storm sidnei (~sidnei@189-10-225-244.cslce701.dsl.brasiltelecom.net.br) |
| 12:16.29 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 12:23.01 | *** join/#storm zmijunkie (~sascha@89.244.144.84) |
| 12:47.03 | *** join/#storm fcorrea (~fcorrea@187.3.22.136) |
| 13:12.52 | *** join/#storm niemeyer (~niemeyer@201-40-152-213.pltce701.dsl.brasiltelecom.net.br) |
| 13:36.49 | *** join/#storm niemeyer (~niemeyer@201-40-152-213.pltce701.dsl.brasiltelecom.net.br) |
| 13:44.08 | *** join/#storm niemeyer (~niemeyer@201-40-152-213.pltce701.dsl.brasiltelecom.net.br) |
| 14:23.48 | *** join/#storm sidnei (~sidnei@201-66-145-56.cslce701.dsl.brasiltelecom.net.br) |
| 14:43.50 | *** join/#storm niemeyer_ (~niemeyer@201-11-241-43.pltce701.dsl.brasiltelecom.net.br) |
| 15:40.06 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 15:48.44 | *** part/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 17:33.58 | *** join/#storm webmaven (~webmaven@97.65.119.2) |
| 18:29.41 | *** join/#storm cr3 (~cr3@64.34.151.178) |
| 18:32.03 | cr3 | hi folks, what might cause all fields in an object to result in an update in the database where most values being updated are the same as before? I'm having a really hard time finding a way to reproduce, so looking for inspiration |
| 18:40.21 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 18:51.23 | *** join/#storm maxb (~maxb@jabberwock.vm.bytemark.co.uk) |
| 18:51.34 | *** join/#storm jdobrien_ (~john@50-88-19-25.res.bhn.net) |
| 18:54.55 | cr3 | put more clearly, in the function decorated by @compile.when(Update), might there be a reason for update.map to contain all storm properties for the object in question? |
| 18:56.56 | therve | cr3, yes, if storm didn't detect that the object has been flushed to the database |
| 18:57.18 | therve | cr3, most of the times, it's a bug in storm. Make sure you use the latest version. Otherwise, well... |
| 19:06.17 | cr3 | therve: out of curiosity, might update.map exclude AutoReload properties in older versions? |
| 19:07.18 | therve | cr3, not that I know... |
| 19:08.04 | cr3 | therve: yeah, just confirmed. I might have to bite the bullet and update |
| 19:08.18 | cr3 | I mean, just confirmed you're right, AutoReload doesn't make a difference |
| 19:18.24 | cr3 | therve: by the way, how can I reproduce that state where storm doesn't detect an object has been flushed? I'd like to be able to reproduce consistently in a test before attempting to fix it |
| 19:19.26 | therve | cr3, it's fairly tricky, but you should be able to see some examples in the test suite already |
| 19:38.51 | *** join/#storm zmijunkie (~sascha@46.115.194.226) |
| 20:31.55 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 21:10.11 | lifeless | cr3: that was a bug a few releases back |
| 21:10.18 | lifeless | cr3: what storm version are you running ? |
| 21:16.54 | cr3 | lifeless: I was running 0.16.0.99, merging from revno 386 (0.18.0.99) seems to have fixed the problem. I finally managed to reproduce the problem reliably and it didn't occur anymore after the merge. |
| 21:18.47 | lifeless | yeah |
| 21:18.51 | lifeless | lp ran into this last year |
| 21:19.02 | lifeless | took quite a bit to convince therve the problem was real :P |
| 21:20.17 | cr3 | lifeless: took quite a bit of convincing to myself that the problem was indeed in storm, I have quite a bit of magic around it to handle integration with salesforce |
| 21:22.28 | cr3 | lifeless: I'm pleased all of you managed to fix this, great win for me. thanks everyone! |
| 21:27.39 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 21:58.53 | *** join/#storm wallyworld (~quassel@27-33-46-253.static.tpgi.com.au) |
| 22:59.09 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 22:59.31 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 23:33.50 | *** join/#storm fcorrea (~fcorrea@201-62-110-81-ma.static.vivax.com.br) |