00:33.04 | *** join/#storm danilo_ (n=danilo@static-213-198-236-193.adsl.eunet.rs) |
00:53.31 | *** join/#storm srichter (n=quassel@c-76-19-135-180.hsd1.ma.comcast.net) |
02:32.25 | *** join/#storm srichter (n=quassel@c-76-19-135-180.hsd1.ma.comcast.net) |
03:07.03 | *** join/#storm stub (n=stub@ppp-58-8-209-252.revip2.asianet.co.th) |
03:39.19 | *** join/#storm vvinet (n=vince@modemcable041.205-203-24.mc.videotron.ca) |
04:11.28 | *** join/#storm danilo_ (n=danilo@static-213-198-236-193.adsl.eunet.rs) |
04:32.08 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
05:47.16 | *** join/#storm jtv (n=jtv@125.25.151.108.adsl.dynamic.totbb.net) |
06:06.20 | *** join/#storm jukart (n=jukart@d86-32-163-51.cust.tele2.at) |
06:51.19 | *** join/#storm mikex2 (n=mikael@193.11.22.34) |
06:52.32 | *** join/#storm jukart (i=lovely@81.189.156.94) |
07:00.15 | *** join/#storm keppla (n=keppla@i577B3F9A.versanet.de) |
07:56.49 | jtv | therve: back? |
07:57.18 | jtv | We just got a weird one over in Launchpad. |
07:57.37 | therve | jtv: yep? |
07:58.16 | jtv | Reading some object's primary id calls _resolve_lazy_value, which calls flush, which creates an object with a primary key value that was already taken! |
07:58.37 | jtv | This is a plain old serial id |
07:58.55 | jtv | using 0.15 afaict |
07:59.18 | therve | hum... |
07:59.21 | jtv | and I'd he highly surprised if we did anything nasty like update the id... |
07:59.47 | jtv | ...or manipulate the sequences. |
07:59.58 | therve | thinks of another bug |
08:03.40 | therve | jtv: it's an object you just inserted right? |
08:04.09 | jtv | therve: should be, yes. We're looking into another possibility though: that our test framework for some reason resets the sequence but not the table |
08:04.37 | therve | ah |
08:05.33 | therve | it looks more like a possibility :) |
08:06.20 | therve | you can trace the query and see what is the RETURNING clause, just to check |
08:07.46 | jtv | wouldn't that be field names though? |
08:08.04 | therve | right |
08:31.42 | jtv | Phew, it was indeed a stupid test isolation problem in LP. Sorry about the false alarm! |
08:50.23 | jamesh | therve: do you think much would break if EventSystem used weakrefs to automatically remove callbacks? |
08:53.09 | therve | jamesh: I've been wondering about that |
08:53.17 | therve | it would worth trying |
08:54.41 | therve | note that we should still unhook manually |
08:54.55 | jamesh | therve: the django.dispatch.saferef module has the code in question for handling weakrefs to instance methods |
09:03.26 | *** join/#storm elmom_ (n=elmom@vallila-gw.hupnet.helsinki.fi) |
09:07.09 | *** join/#storm mikex2 (n=mikael@193.11.22.34) |
09:57.01 | *** join/#storm zmijunkie (n=chatzill@89.245.244.182) |
10:08.02 | *** join/#storm mup (n=mup@li37-90.members.linode.com) |
10:41.52 | *** join/#storm artista_frustrad (n=artista_@201-35-1-111.ctame704.dsl.brasiltelecom.net.br) |
10:44.12 | *** join/#storm elmom_ (n=elmom@128.214.20.122) |
11:21.34 | *** join/#storm elmom_ (n=elmom@128.214.20.122) |
11:36.47 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) [NETSPLIT VICTIM] |
11:36.48 | *** join/#storm \sh (n=nsherman@newzealand.sourcecode.de) [NETSPLIT VICTIM] |
11:42.11 | *** join/#storm fcorrea (n=fcorrea@187.3.137.148) |
12:01.10 | *** join/#storm niemeyer (n=niemeyer@201-89-133-78.pltce701.dsl.brasiltelecom.net.br) |
13:22.01 | *** join/#storm artista_frustrad (n=artista_@200-193-162-75.ctame704.dsl.brasiltelecom.net.br) |
13:22.32 | *** join/#storm vvinet (n=vince@132.210.76.197) |
13:24.55 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
13:40.22 | *** join/#storm srichter (n=quassel@75.150.101.45) |
15:31.22 | *** join/#storm artista_frustrad (n=artista_@201-24-207-234.ctame704.dsl.brasiltelecom.net.br) |
15:41.16 | *** join/#storm danilo_ (n=danilo@cable-94-189-247-236.dynamic.sbb.rs) |
16:15.14 | *** join/#storm infobot (i=ibot@rikers.org) |
16:15.14 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.15 released! || Review branches: https://code.launchpad.net/storm/+activereviews || IRC logs: http://ibot.rikers.org/#storm/ || API documentation: http://people.canonical.com/~jkakar/storm/ |
16:38.05 | *** join/#storm Ursinha (n=ursula@canonical/launchpad/ursinha) |
16:38.17 | Ursinha | niemeyer, maybe it's better here :) |
16:38.41 | niemeyer | Ursinha: Works too :) |
16:38.52 | Ursinha | niemeyer, :) so |
16:39.38 | Ursinha | niemeyer, I was doing stuff with storm a few days ago, and an assertEquals failed to me because I was comparing a POFile.field with a Max(POFile.field) |
16:40.20 | Ursinha | niemeyer, is it expected that Max returns what's in the database, and not as it's declared in the model? |
16:41.04 | Ursinha | basically it was failing because the field was a datetime naive in the db, but utc in the model |
16:42.22 | niemeyer | Ursinha: Hmmmm |
16:43.46 | niemeyer | Ursinha: This may be an interesting problem to solve |
16:43.56 | Ursinha | niemeyer, cool, did I find a bug? |
16:44.12 | niemeyer | Ursinha: Yeah, I guess it may be seen as a bug |
16:44.17 | Ursinha | woot |
16:44.48 | niemeyer | Ursinha: The issue is that *some* aggregation functions could try to dig in the model to see which data type to use |
16:45.07 | niemeyer | Ursinha: E.g., it doesn't make sense for Count |
16:45.15 | niemeyer | Ursinha: But for Max, it could be enhanced |
16:45.18 | *** join/#storm elmom_ (n=elmom@82.181.200.16) |
16:45.21 | Ursinha | niemeyer, yeah |
16:45.23 | Ursinha | agreed |
16:45.47 | niemeyer | Ursinha: Would you mind to file a bug about this so that we don't forget? |
16:46.14 | Ursinha | niemeyer, of course not, just haven't done that yet because wanted to talk to you first :) |
16:46.28 | niemeyer | Ursinha: Super, thanks a lot for the report |
16:46.48 | Ursinha | niemeyer, no problem! :) |
16:49.27 | Ursinha | niemeyer, maybe I can go crazy and take a look at the code to see how hard is it to fix :P |
16:51.14 | niemeyer | Ursinha: Oh, that'd be fantastic! |
16:52.58 | niemeyer | Ursinha: If you dig in, have a look at Comparable in expr.py.. we'll likely have to implement some logic in ResultSet._aggregate() (in store.py) which reminds that of the is_in() and friends in Comparable. |
16:53.28 | Ursinha | sure! thanks a lot for the pointers |
16:53.33 | Ursinha | niemeyer, I think I'll give it a go then |
16:54.13 | niemeyer | Ursinha: Sweet! |
17:05.47 | *** join/#storm niemeyer_ (n=niemeyer@201-25-43-207.pltce701.dsl.brasiltelecom.net.br) |
17:08.08 | *** join/#storm artista_frustrad (n=artista_@201-24-231-81.ctame704.dsl.brasiltelecom.net.br) |
18:16.54 | *** join/#storm drudi (n=drudi@187.46.115.86) |
19:10.34 | *** join/#storm srichter_ (n=quassel@75.150.101.45) |
20:52.03 | *** join/#storm elmom_ (n=elmom@hoasnet-fe29dd00-137.dhcp.inet.fi) |
21:11.31 | *** join/#storm niemeyer (n=niemeyer@201-25-43-207.pltce701.dsl.brasiltelecom.net.br) |
21:25.42 | *** join/#storm elmom (n=elmom@hoasnet-fe29dd00-137.dhcp.inet.fi) |
21:45.13 | *** join/#storm seiflotfy (n=seif@P5118.pallas.wh.tu-darmstadt.de) |
22:34.04 | *** join/#storm shaunm (n=shaunm@c-98-212-133-244.hsd1.il.comcast.net) |
23:12.44 | *** join/#storm vvinet (n=vince@modemcable041.205-203-24.mc.videotron.ca) |