00:00.33 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
01:10.22 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
01:38.44 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
03:31.48 | *** join/#storm fcorrea (n=fcorrea@c953f7fd.virtua.com.br) |
05:17.35 | thumper | how do you check for "table.field is not NULL" ? |
05:17.43 | thumper | in a store.find clause? |
05:17.59 | jml | != None, I bet |
05:17.59 | ubot3 | Factoid none, i bet not found |
05:18.08 | jml | heh heh |
05:18.20 | jml | possibly even 'is not None' |
05:18.40 | jml | although probably not. |
05:51.44 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
06:24.24 | jamesh | thumper: column or reference? |
06:24.37 | thumper | reference |
06:24.42 | thumper | does it matter? |
06:24.49 | jamesh | for a column, "!= None" should work. For a reference, there is a bug. |
06:25.14 | jamesh | https://bugs.edge.launchpad.net/storm/+bug/244768 |
06:25.18 | ubot3 | Malone bug 244768 in storm "Reference != None returns True, not an expression" [Undecided,New] |
06:25.30 | thumper | arse |
06:25.51 | thumper | jamesh: work around? |
06:25.56 | jamesh | for now, either use the column backing the reference or use not (reference == None) |
06:26.10 | thumper | nods |
06:26.22 | jamesh | or write a patch to fix the bug :) |
06:26.23 | thumper | jamesh: I was also looking for the update statement which updates multiple rows |
06:26.37 | thumper | jamesh: but I couldn't find it in the tutorial |
06:26.50 | jamesh | thumper: ResultSet.set() |
06:27.22 | thumper | jamesh: ta |
06:27.29 | jamesh | thumper: it is a bit limited at the moment though: it'll produce bad SQL for result sets that do joins |
06:27.46 | thumper | jamesh: I just want to set a column on the entire table |
06:27.56 | jamesh | we should be able to add handling for joins for postgresql and mysql though |
06:28.06 | thumper | jamesh: so store.find(TableName).set(column=value) should be fine |
06:28.13 | jamesh | yep. |
06:28.16 | thumper | cool |
06:30.58 | jamesh | jml: I don't think you can hook "is" or "is not" in Python |
06:31.13 | jml | jamesh: right. |
06:31.31 | jml | jamesh: I resolved that a little after my comment. |
06:31.33 | jamesh | except maybe with bytecode hacks :) |
06:31.39 | jml | jamesh: right :) |
06:31.48 | jml | jamesh: gentlemen don't mention such things. |
07:42.18 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
08:39.46 | *** join/#storm lightyear (n=ben@nat/fluendo/x-02cdc795356dbc0a) |
11:57.09 | *** join/#storm jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
11:57.09 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.12 released! || Review branches: https://code.launchpad.net/~storm/storm/trunk/+landing-candidates |
12:37.05 | *** join/#storm niemeyer (n=niemeyer@200-103-247-127.ctame705.dsl.brasiltelecom.net.br) |
13:02.30 | *** join/#storm mup (n=mup@200-103-247-127.ctame705.dsl.brasiltelecom.net.br) |
18:38.41 | *** join/#storm kov (i=kov@debian/developer/kov) |
19:11.13 | *** join/#storm kov (i=kov@debian/developer/kov) |
20:24.41 | *** join/#storm kov (i=kov@debian/developer/kov) |
20:38.28 | oohlaf | anyone alive? |
20:38.37 | oohlaf | I have a question on inheritance |
20:47.11 | oohlaf | hmm, I'll post to the mailinglist |
20:55.37 | jkakar | oohlaf: 'sup? |
20:56.11 | jkakar | I'm reading your post now... |
20:56.29 | oohlaf | cool |
20:56.59 | jkakar | oohlaf: I think I see what's going on: when Employee subclasses Person it defines a new __storm_table__ which must have the fields required by both Employee and Person. |
20:57.07 | jkakar | oohlaf: ie: Storm doesn't support table inheritance. |
20:58.03 | oohlaf | ok, because the books on oo - relational mapping mention having a common table for shared properties |
20:58.10 | oohlaf | and use foreign keys in the subclasses |
20:58.53 | jkakar | oohlaf: We had a system that could do that kind of thing, but it was complicated and we didn't feel it yielded much benefit, so we got rid of it. You can see bits of it in the log at r107. |
21:00.04 | jkakar | oohlaf: We've had to deal with the inheritance problem in Landscape. For example, say you had cars, you'd have a base Car class. This would back onto the 'car' table and contain properties and behaviour common to all cars. |
21:01.05 | jkakar | Onto this Car object you'd tack a .info property that yields and object with data specific to a type of car. You can have CarInfo, PickupTruckInfo and MotorbikeInfo objects, each storing specific data in a storm table and exposing specific behaviour. |
21:01.57 | jkakar | oohlaf: That turns out to be nice because you can easily query by subclass, because there's a table for each one. Having the .info indirection seems like it'd be annoying, but it turns out to be a nice hint that says, "some custom logic is being exercised here". |
21:02.41 | oohlaf | and how is the info defined? |
21:02.50 | oohlaf | the property |
21:03.43 | oohlaf | does it do a find()? |
21:05.05 | oohlaf | I imagine that the *Info tables (like CarInfo) have a Reference to Car.id |
21:05.15 | oohlaf | but only one way? |
21:12.57 | jkakar | oohlaf: Each info class is registered with the "car info registry"; in effect, you need a binding of int info type ID -> info class. Car has an info_type column that stores this ID. Car.info is a property that uses the info_type to get the info class type which it uses to run a find. |
21:15.21 | oohlaf | can you pastebin an example? I tried to make something like that by returning a Reference(id, type_id) |
21:15.27 | oohlaf | but did not succeed |
21:15.55 | oohlaf | or reply to my mail? |
21:22.10 | jkakar | oohlaf: Hmm, yeah, it's a bit involved for me to pastebin right now. I'll prepare a response to your mail later on today talking about it. |
21:22.41 | oohlaf | ok, thanks, looking forward to it |