| 00:00.19 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 00:27.01 | shaunm | how does transaction management with sqlite work exactly? |
| 00:27.32 | shaunm | according to the sqlite documentation, sqlite works in "autocommit mode" unless the "BEGIN TRANSACTION" command is ussed |
| 00:27.37 | shaunm | *issued |
| 00:28.00 | shaunm | and COMMIT reverts it back to autocommit, so you need another BEGIN TRANSACTION |
| 00:28.16 | shaunm | does storm automatically issue BEGIN TRANSACTION commands that I'm not seeing? |
| 00:50.39 | jkakar | shaunm: Yes, it does. |
| 00:51.11 | jkakar | shaunm: You have store.commit() and store.rollback() to decide how the transaction ends. It begins automatically. |
| 00:51.48 | shaunm | ok |
| 00:52.08 | shaunm | just surprised it doesn't show up with a debug tracer on |
| 01:13.49 | *** join/#storm artista-frustrad (n=artista_@201-40-95-59.ctame704.dsl.brasiltelecom.net.br) |
| 01:29.30 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 02:47.01 | *** join/#storm goschtl (n=goschtl@p5B0BBA94.dip.t-dialin.net) |
| 03:16.55 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 05:00.40 | *** join/#storm artista-frustrad (n=artista_@201-15-218-10.ctame704.dsl.brasiltelecom.net.br) |
| 05:11.35 | *** join/#storm bigdog1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:19.39 | *** join/#storm bigdog1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:27.05 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 05:50.46 | *** join/#storm jukart (n=jukart@d91-128-122-97.cust.tele2.at) |
| 06:44.47 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 09:50.41 | *** join/#storm goschtl (n=goschtl@p5B0BBA94.dip.t-dialin.net) |
| 12:11.20 | *** join/#storm uzzed (n=alexandr@200.139.120.198.dynamic.adsl.gvt.net.br) |
| 12:25.44 | *** join/#storm niemeyer (n=niemeyer@200-103-244-201.ctame705.dsl.brasiltelecom.net.br) |
| 12:41.09 | *** join/#storm andrea-bs (n=andrea-b@ubuntu/member/beeseek.developer.andrea-bs) |
| 12:51.52 | *** join/#storm gord (n=gord@5ac7ea62.bb.sky.com) |
| 12:57.04 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 13:31.38 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 13:38.27 | *** join/#storm vvinet (n=vince@132.210.76.200) |
| 14:06.34 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 14:14.05 | *** join/#storm thumper (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 14:16.15 | grahame | anyone about? |
| 14:16.40 | grahame | I have some ideas to speed up storm for some uses (iterating over large numbers of results), and wondering if they'd be merged |
| 14:18.04 | therve | grahame: ideas don't get merged, code does :) |
| 14:18.09 | grahame | well, yeah |
| 14:18.21 | grahame | I'm iterating over lots of rows, say about 3 million |
| 14:18.30 | therve | that's a lot |
| 14:18.31 | grahame | in that case, caching makes pretty much no sense |
| 14:18.56 | grahame | so I was thinking I'd modify things to notice when a particular iterator has yielded "lots" (say the cache size / 2) of rows |
| 14:19.00 | grahame | and then stop caching the results |
| 14:19.40 | grahame | it'd have the advantage of speeding up queries returning a lot of rows, and also mean that the cache doesn't get wiped out by large numbers of results you'll never look at again |
| 14:20.06 | grahame | a bit of experimentation suggests it'd make things about as fast as the django ORM for the case of big result sets |
| 14:20.35 | jamesh | grahame: niemeyer merged a more efficient cache implementation recently, although it is not selected by default |
| 14:21.29 | grahame | ah, GenerationalCache |
| 14:21.32 | grahame | I'll have a look, thanks |
| 14:22.25 | jamesh | grahame: the default cache uses a straight LRU cache, which is pretty inefficient. The GenerationalCache essentially manages two caches, clearing one then rotating when the active one fills up |
| 14:22.53 | jamesh | so doesn't have to manage an LRU list |
| 14:25.17 | jamesh | grahame: it'll probably be made the default cache implementation in future |
| 14:25.45 | grahame | jamesh: there deosn't seem to be much performance difference for my test |
| 14:26.01 | grahame | jamesh: it's kind of a worst case for any cache though; it seems sensible to notice and stop caching |
| 14:26.27 | grahame | jamesh: the code in Store._load_object to calculate the cache key seems fairly expensive too |
| 14:26.58 | grahame | (it might just be I'm using the wrong tool, and should just not use storm in this way) |
| 14:28.01 | jamesh | grahame: yeah. The cache key bit would be a good thing to look at optimising |
| 14:28.40 | grahame | jamesh: do you think a patch to notice the current query is swamping the cache and stop caching would make it in? then we skip all that code |
| 14:28.55 | jamesh | we used to have something faster in there but it caused other problems (previously the Variable instances were hashable and being used directly) |
| 14:29.42 | jamesh | grahame: we'd still need to push things through the store._alive weak dict |
| 14:30.05 | grahame | jamesh: yeah, I was wondering about that |
| 14:30.51 | grahame | I might just sneak in behind storm and use it to build me a query, then run it directly |
| 14:31.06 | grahame | I'm using storm to build a database from google transit feeds |
| 14:31.14 | grahame | then doing silly things like drawing maps from the data |
| 14:31.29 | jamesh | because it is easier than getting things from transperth? :) |
| 14:31.35 | grahame | yeah, pretty much |
| 14:31.46 | grahame | ./armada.py stop_timetable sqlite:perth.db 17586 |
| 14:31.53 | grahame | gives me the timetable for the stop near my house |
| 14:31.56 | grahame | a lot easier! |
| 14:32.26 | jamesh | is that the bus stop number or some other key? |
| 14:32.33 | grahame | that's the bus stop number |
| 14:32.50 | grahame | the numbers on the transperth stop signs actually match the bus stop numbers in the feed, too |
| 14:33.07 | jamesh | cool. |
| 14:33.11 | grahame | I've got a pretty map of all the routes too |
| 14:33.33 | grahame | just trying to make it usefully fast now, the mapping stuff spends most of its time in storm |
| 14:33.53 | *** join/#storm gord (n=gord@5ac7ea62.bb.sky.com) |
| 14:34.39 | jamesh | if you are after just a few numbers, result_set.values(columns) might help. |
| 14:37.39 | grahame | wow, that's exactly what I needed |
| 14:37.49 | grahame | I definitely owe you a beer :-) |
| 14:38.05 | grahame | that's stupidly fast too |
| 14:41.14 | jamesh | we really need better documentation :( |
| 14:41.52 | grahame | well, I don't mind writing something about this |
| 14:42.20 | grahame | shrugs |
| 14:53.27 | jamesh | there are a bunch of methods that let you work with a result set as a whole rather than retrieving each value |
| 14:53.38 | jamesh | and there are more we could add. |
| 14:54.16 | grahame | all that's needed is a little addition to the tutorial discussing them |
| 15:04.58 | jamesh | well, I think we probably need something more than just a tutorial. |
| 15:06.01 | jamesh | a tutorial that includes absolutely everything is probably not that good at teaching new users |
| 15:06.14 | jamesh | and tutorials are not the best form of reference for existing users |
| 15:28.19 | *** join/#storm shaunm (n=shaunm@proxyserver.wolfram.com) |
| 15:31.36 | *** join/#storm uzzed1 (n=alexandr@189.115.81.82) |
| 15:34.11 | grahame | you could perhaps call it a cookbook |
| 15:34.39 | grahame | just a list of problems and suggested solutions |
| 15:35.12 | *** part/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 16:03.10 | *** join/#storm deryck (n=deryck@samba/team/deryck) |
| 16:25.26 | mup | storm/result-set-in-subselects r299 committed by jkakar@kakar.ca |
| 16:25.27 | mup | - New ResultSet.select method returns a Select expression based on |
| 16:25.27 | mup | <PROTECTED> |
| 16:25.27 | mup | <PROTECTED> |
| 16:27.20 | *** join/#storm andrea-bs (n=andrea-b@ubuntu/member/beeseek.developer.andrea-bs) |
| 16:35.30 | mup | storm/result-set-in-subselects r300 committed by jkakar@kakar.ca |
| 16:35.30 | mup | - EmptyResultSet has an implementation of the new select method. |
| 16:43.06 | jkakar | If anyone has spare review cycles I've put a small Storm branch in review: bug #337494 |
| 16:43.07 | mup | Bug #337494: Use ResultSets in subselects <review> <Storm:In Progress by jkakar> <https://launchpad.net/bugs/337494> |
| 16:43.14 | shaunm | is there any way storm would be trying to do multiple transaction where there is one process with one thread using one Store object? |
| 16:44.04 | jkakar | shaunm: Not unless you have more than one Store in use. |
| 16:44.47 | shaunm | I am completely baffled as to how I'm getting this "database table is locked" error |
| 16:45.23 | radix | shaunm: do you have a simple script that can reproduce it? |
| 16:46.33 | shaunm | unfortunately, no |
| 16:47.10 | shaunm | and I'm able to get through the same code paths successfully for some other objects I process |
| 16:47.48 | shaunm | hmm, I could try to put something together |
| 16:48.37 | jkakar | Crap, there's a failing MySQL test in my branch. |
| 16:50.39 | *** part/#storm philn (n=phil@o.bcn.fluendo.net) |
| 16:53.26 | jamesh | jkakar: if you propose it for merging, it'll show on the active reviews pages |
| 16:53.34 | jamesh | and LP will generate diffs |
| 16:53.45 | *** topic/#storm by jamesh -> The Storm Python ORM - http://storm.canonical.com/ - 0.14 released! || Review branches: https://code.launchpad.net/storm/+activereviews |
| 16:54.08 | jkakar | jamesh: Oh right, I completely forgot about that step for some reason. Thanks. :) |
| 16:55.00 | shaunm | ooh |
| 16:55.12 | *** join/#storm deryck_ (n=deryck@24-179-42-225.dhcp.leds.al.charter.com) |
| 16:55.14 | shaunm | how does storm actually do iterators over ResultSet objects? |
| 16:55.23 | mup | storm/result-set-in-subselects r301 committed by jkakar@kakar.ca |
| 16:55.23 | mup | - Don't return a real Select expression from EmptyResultSet.select |
| 16:55.23 | mup | <PROTECTED> |
| 16:55.23 | mup | <PROTECTED> |
| 16:55.45 | jamesh | shaunm: you can iterate over a result set, if that's what you're asking. |
| 16:56.15 | shaunm | jamesh: I know I can. I'm asking what it actually does with the database when I'm doing that |
| 16:56.40 | shaunm | because I only get the locking error after I enter this iterator |
| 16:58.06 | jamesh | shaunm: it will execute the query and read the results in blocks with fetchmany() |
| 16:58.12 | shaunm | yup, that's the problem. if I wrap the ResultSet with list() before iterating, error goes away |
| 16:58.41 | shaunm | jamesh: hence leaving an open query on the database, causing UPDATEs to fail |
| 16:58.44 | jamesh | I don't think SQLite likes you doing extra queries while keeping a previous result set open |
| 16:58.53 | shaunm | yeah |
| 16:59.26 | mup | storm/result-set-in-subselects r302 committed by jkakar@kakar.ca |
| 16:59.26 | mup | - Remove unnecessary untested code. |
| 17:01.48 | shaunm | jamesh: so by forcing this into a list, am I substantially hurting performance for a problem that will only manifest with sqlite? |
| 17:03.00 | shaunm | in this particular case, the upper bound for how many rows might be returned is basically the number of languages gnome is translated into |
| 17:03.03 | jamesh | shaunm: if you're always going to use all items in the result set, and it isn't ever going to be overly large, it won't hurt performance much. |
| 17:03.18 | shaunm | ok |
| 17:03.58 | shaunm | I'll leave it in, with a comment, and just be mindful of things like this |
| 17:07.37 | shaunm | I need to do some refactoring to avoid excessive UPDATE commands |
| 17:17.32 | shaunm | five crawler modules down, six to go |
| 17:20.14 | *** part/#storm goschtl (n=goschtl@p5B0BBA94.dip.t-dialin.net) |
| 17:25.42 | jamesh | jkakar: looks like an interesting branch. I wonder if turning Foo.bar.is_in(result_set) to Foo.bar.is_in(result_set.select(Foo.bar)) would be appropriate? |
| 17:26.55 | jkakar | jamesh: That was actually what I'd originally planned, but it means s.expr.Comparable.is_in needs to be special-cased to know about ResultSet, which feels dirty. |
| 17:27.23 | jamesh | jkakar: well, Column.is_in could special case it ... |
| 17:27.26 | jkakar | jamesh: I thought about using and interface, with adaptation or something, to make is_in more generically able to transform its inputs, but decided that was more than I cared about. |
| 17:28.01 | jamesh | btw, theres a few of my branches still waiting for review :) |
| 17:28.01 | jkakar | jamesh: Sure, Column is probably a better place for it even, but it still feels a bit leaky. OTOH, I totally agree with you that it's a nicer API. |
| 17:28.22 | jkakar | jamesh: I'll make some time for them today. :) |
| 17:28.29 | jamesh | thanks |
| 17:43.04 | jkakar | jamesh: Thanks for your review comments, all make sense. |
| 17:43.22 | jkakar | jamesh: I'm not happy with the EmptyResultSet.select behaviour right now, either. |
| 17:43.45 | jamesh | jkakar: the other reason for going with a real Select() in EmptyResultSet is that the Select will have the right number of columns |
| 17:46.44 | jkakar | jamesh: Yeah. |
| 17:47.35 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 17:48.49 | jkakar | jamesh: for the "test on a set expression result set" what do you mean exactly? |
| 17:49.18 | jamesh | jkakar: something like result1.union(result2).select() |
| 17:49.19 | mup | storm/result-set-in-subselects r303 committed by jkakar@kakar.ca |
| 17:49.19 | mup | - EmptyResultSet.select returns a Select expression instead of an |
| 17:49.20 | mup | <PROTECTED> |
| 17:49.35 | jkakar | jamesh: Ah, I see, okay, thanks. |
| 17:49.37 | jamesh | probably best to use unions for the example, since I think that's the only one mysql supports |
| 17:49.56 | jamesh | jkakar: feel free to raise an exception in such cases if it looks too hard to handle |
| 17:55.58 | jkakar | jamesh: That's what I'm thinking. There's actually a similar issue with values. result1.union(result2).values(Foo.bar) blows up. |
| 18:00.57 | mup | storm/result-set-in-subselects r304 committed by jkakar@kakar.ca |
| 18:00.58 | mup | - ResultSet.select and ResultSet.values both raise Feature error if |
| 18:00.58 | mup | <PROTECTED> |
| 18:00.58 | mup | <PROTECTED> |
| 18:02.19 | jamesh | jkakar: there is some code in the ResultSet.__contains__() implementation that could probably be used to handle set expressions |
| 18:02.37 | jamesh | using the replace_columns() helper function |
| 18:03.33 | jkakar | jamesh: Ah, good eye. I think that looks workable. |
| 18:07.05 | jamesh | I think I wrote that code after radix complained about my __contains__() implementation breaking union result sets |
| 18:16.06 | jamesh | having LP generate diffs for the reviews is pretty cool |
| 18:44.12 | *** join/#storm sidnei_ (n=sidnei@189.30.217.33) |
| 18:45.34 | *** join/#storm sidnei__ (n=sidnei@189.30.217.33) |
| 18:51.45 | mup | storm/result-set-in-subselects r305 committed by jkakar@kakar.ca |
| 18:51.45 | mup | - Merged trunk. |
| 18:54.33 | mup | storm/result-set-in-subselects r306 committed by jkakar@kakar.ca |
| 18:54.33 | mup | - Updated NEWS file. |
| 18:57.30 | shaunm | hmm, another locking issue |
| 18:57.52 | shaunm | issuing a bunch of CREATE TABLE statements, then I get a database-locked error on COMMIT |
| 18:58.57 | shaunm | CREATE statements done with store.execute(cmd, noresult=True) |
| 18:59.25 | shaunm | not a single SELECT or other statement being printed out by the debugger |
| 19:13.56 | shaunm | ok, if I commit after each one, I get the error after the first command that actually creates a table |
| 19:14.04 | shaunm | (they're all "IF NOT EXISTS") |
| 19:14.50 | shaunm | so does "CREATE TABLE IF NOT EXISTS" leave something open with sqlite when the table does exist? |
| 19:14.58 | jkakar | shaunm: What happens if you call store.flush() between CREATE TABLE statements? |
| 19:15.16 | jkakar | shaunm: Actually, scratch that, that was crack, sorry. |
| 19:15.16 | shaunm | same |
| 19:24.39 | shaunm | suppose I could just do that one table creation manually and move on with things |
| 19:25.26 | shaunm | not much point in spending time on an issue that only happens when I add a table and only with a database that I only use for testing |
| 19:27.00 | shaunm | oh |
| 19:27.18 | shaunm | my database is just flat-out locked. not a storm thing at all |
| 19:31.29 | shaunm | probably a stale lock from me killing the crawler when it was doing something stupid. anybody happen to know how to get this lock off? |
| 19:34.47 | shaunm | son of a bitch |
| 19:35.19 | shaunm | I had a python session running where I was futzing around with stuff |
| 19:35.28 | shaunm | sorry for the stupidity |
| 19:37.25 | radix | hehe |
| 19:47.10 | jamesh | eventually you'll want a real database |
| 19:57.32 | shaunm | jamesh: of course. sqlite is just for testing. I've run pulse off of mysql before |
| 19:57.45 | shaunm | using django. haven't tried it yet with storm |
| 19:58.04 | shaunm | but obviously, the goal for production use is mysql or postgres |
| 19:58.53 | jamesh | shaunm: you might be better off testing on your target database |
| 19:59.03 | jkakar | Aye |
| 20:07.28 | shaunm | that makes it difficult to run my test instance on gnome.org |
| 20:07.44 | shaunm | with sqlite, I can just upload the database file |
| 20:11.44 | shaunm | plus, I'm not sure I have a concrete target database. I only have experience with mysql, but there are gnome folks who would prefer we did stuff with postgres |
| 20:16.10 | jamesh | fwiw, the PostgreSQL backend to storm probably gets more attention than the MySQL backend |
| 20:16.27 | jamesh | (that said, most database-related tests get run for all three current backends) |
| 20:18.06 | *** join/#storm oubiwann (n=oubiwann@97-119-85-2.omah.qwest.net) |
| 20:20.51 | shaunm | I don't really have the level of database expertise to make an informed decision between the two |
| 20:48.57 | *** join/#storm artista_frustrad (n=artista_@201-25-170-30.ctame704.dsl.brasiltelecom.net.br) |
| 21:10.00 | *** join/#storm artista_frustrad (n=artista_@201-40-94-71.ctame704.dsl.brasiltelecom.net.br) |
| 22:12.17 | *** join/#storm cody-somerville (n=cody-som@ubuntu/member/somerville32) |
| 22:13.04 | cody-somerville | How well does storm work with threads? |
| 22:38.04 | jkakar | jml: https://code.edge.launchpad.net/~jkakar/storm/result-set-in-subselects/+merge/4147 |
| 22:38.23 | jml | jkakar: thanks |
| 22:38.37 | jml | looks |
| 22:38.51 | jml | jkakar: do you need another review? |
| 22:38.58 | jkakar | jml: It was fun. Also, FYI, for some reason the diff on that merge page is several revisions and several hours out of date. |
| 22:39.12 | jkakar | jml: Yes please! Once I have a second review taken care of I can merge it. |
| 22:39.44 | jml | jkakar: it's the revision created when you originally submit the merge proposal |
| 22:39.52 | jml | jkakar: that's a feature, not a bug. |
| 22:40.41 | jml | jkakar: the "diff against target" feature should show the current diff. |
| 22:41.19 | jkakar | jml: It's confusing because it says "Review Diff", but isn't what should be reviewed. |
| 22:42.07 | jkakar | jml: Am I doing something wrong? |
| 22:43.01 | jml | jkakar: well... |
| 22:43.04 | jml | jkakar: no, you aren't. |
| 22:43.33 | jml | jkakar: the idea is that the when you propose a branch for merging, the diff you want reviewed is the current head of that branch |
| 22:43.46 | jkakar | jml: Right, that makes sense. |
| 22:43.55 | jml | jkakar: this is how bzr send works, for example. |
| 22:44.07 | jml | jkakar: there should *probably* be a way to update the diff |
| 22:44.26 | jml | jkakar: but there's some internal contention on this. |
| 22:45.10 | jkakar | jml: So, the thing that's weird for me is that I've made changes based on review feedback from jamesh, but the diff doesn't reflect that and is misleading for users that don't know they should bzr branch $branch and look at the real diff. |
| 22:46.00 | jkakar | jml: I mean, I guess no one should review a branch without really getting it and running its tests, etc., but from a convenience point of view being able to re-review minor changes just by looking at the diff on the web would be nice. |
| 22:46.15 | jml | jkakar: yeah. |
| 22:46.22 | jml | jkakar: I agree 100% with that. |
| 22:46.23 | jkakar | jml: Would it help if I filed a bug? |
| 22:46.29 | thumper | hello? |
| 22:46.33 | jkakar | thumper: Hey! |
| 22:46.37 | jml | jkakar: yes please, but wait a moment or two for thumper to catch up :) |
| 22:46.41 | jkakar | Heh |
| 22:46.44 | thumper | reads |
| 22:47.28 | thumper | I have a plan to work with beuno on this |
| 22:47.34 | jkakar | Cool. |
| 22:47.38 | thumper | to have the most obvious diff be shown |
| 22:47.45 | thumper | so if there is a more up to date preview diff |
| 22:47.49 | thumper | we can show that more |
| 22:47.55 | thumper | however we'd also have the review diff |
| 22:48.00 | thumper | but it would be "closed" |
| 22:48.01 | jkakar | I really think the diff adds a lot of value to the page, btw, Thanks for adding it. :) |
| 22:48.08 | thumper | and load with ajax |
| 22:48.18 | thumper | jkakar: abentley did a lot of it |
| 22:48.23 | thumper | jkakar: I just made it look nice :) |
| 22:50.37 | jkakar | thumper: Is there any value in me filing a bug about this? |
| 22:54.01 | thumper | jkakar: always |
| 23:00.38 | jamesh | thumper: I also noticed that jkakar's branch is the only one showing a diff inline. Is that just because the older proposals were from before the Launchpad update? |
| 23:01.23 | thumper | jamesh: probably |
| 23:01.49 | thumper | jamesh: I'm running lp:mad for storm, so the preview diff should be up to date |
| 23:02.43 | jamesh | thumper: I was comparing https://code.edge.launchpad.net/~jkakar/storm/result-set-in-subselects/+merge/4147 with https://code.edge.launchpad.net/~therve/storm/twisted-integration/+merge/3733 |
| 23:02.46 | thumper | can we use an order by on a result set |
| 23:02.53 | thumper | that already has an order by clause? |
| 23:02.58 | thumper | looks |
| 23:03.22 | jkakar | thumper: result.order_by(Foo.bar, Foo.baz, ...)? |
| 23:03.23 | thumper | jamesh: the code to auto generate the review diff landed around merge 4000 |
| 23:03.41 | thumper | jkakar: we have a function that already provides an order_by |
| 23:03.47 | thumper | jkakar: and we want to override the ordering |
| 23:04.08 | jml | rs.order_by(...).order_by(...), where the second makes the first irrelevant |
| 23:04.46 | jkakar | thumper: Just call .order_by again. |
| 23:05.49 | jkakar | On this topic, you guys know about __storm_order__, right? |
| 23:05.51 | jamesh | thumper: the librarian file diffs look okay. I was just noticing that jkakar's branch had a pretty printed diff on the proposal page while the others did not. |
| 23:06.04 | thumper | jamesh: that's on my todo list |
| 23:06.21 | thumper | jamesh: almost certainly, they'll start looking nice in the next week or so on edge |
| 23:06.21 | jamesh | thumper: this is really cool, by the way :) |
| 23:06.29 | thumper | I'm glad you like it |
| 23:07.11 | jkakar | thumper: bug #338002 |
| 23:07.12 | mup | Bug #338002: 'Review Diff' on merge proposal page can be out-of-date <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/338002> |
| 23:07.40 | thumper | jkakar: thanks I'll triage later |
| 23:12.01 | jamesh | jkakar: so, do you think having ResultSet.find() and ResultSet.select() would be confusing? |
| 23:12.20 | jamesh | [not that we have ResultSet.find() yet] |
| 23:13.15 | jkakar | jamesh: I was wondering about it and didn't have a clear feeling about it. |
| 23:13.41 | jamesh | I think jml asked about ResultSet.find() once |
| 23:13.44 | jkakar | jamesh: One thought was to call it ResultSet.get_select or get_select_expr, but I kind of like verbs. |
| 23:13.59 | jml | did I? |
| 23:14.15 | jml | oh yeah, I did. |
| 23:14.26 | jamesh | jml: I think it was you. A way to narrow down an existing result set |
| 23:14.29 | jml | yeah |
| 23:14.38 | jml | actually, I've got some code that you guys might want to look at |
| 23:14.42 | jkakar | like to add extra where query parameters? |
| 23:15.45 | jamesh | jkakar: yeah. |
| 23:15.56 | jkakar | I'm not sure 'find' is the right name for that. |
| 23:16.11 | jkakar | Maybe ResultSet.extend? |
| 23:16.48 | jamesh | jkakar: we've got a find() method on bound reference sets that does essentially the same thing |
| 23:16.57 | jml | or restrict() |
| 23:17.00 | jml | or filter() |
| 23:17.05 | jml | (except yay python) |
| 23:18.07 | jkakar | jamesh: It does essentially the same thing yes, but "find me things in this reference set" and "mutate this result set with some custom bits" are quite different things. |
| 23:18.42 | jamesh | jkakar: I wasn't thinking of a method that mutates the result set |
| 23:18.53 | jamesh | have it return a new one |
| 23:18.55 | jkakar | Then again, maybe consistency is better... I guess I don't have a strong opinion about it. I think I'm fine with 'select' unless someone has a better idea. |
| 23:19.19 | jkakar | jamesh: Right, that's what I was thinking, in fact. It's still different from "find me things in this reference set". |
| 23:19.32 | jamesh | really? |
| 23:19.44 | jamesh | it is "find me things in this result set" |
| 23:20.06 | jkakar | Hmm. I guess, okay. |
| 23:21.07 | jml | https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/lib/canonical/launchpad/interfaces//branchcollection.py |
| 23:21.12 | jml | https://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/lib/canonical/launchpad/database//branchcollection.py |
| 23:22.38 | jkakar | Unauthorized. :( |
| 23:22.43 | jml | jkakar: sorry :( |
| 23:23.01 | jml | jkakar: you'll be able to see it in July :) |
| 23:23.40 | jkakar | Heh |