| 00:00.04 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |
| 02:27.17 | *** join/#storm jml_ (n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au) |
| 02:30.04 | *** join/#storm jml_ (n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au) |
| 03:54.38 | *** join/#storm jml (n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net) |
| 04:37.41 | *** join/#storm johnlr (n=johnlr@203-206-162-97.perm.iinet.net.au) |
| 04:47.27 | *** join/#storm dobee (n=dobeee@194.183.146.186) |
| 05:27.30 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 07:31.59 | *** join/#storm mcella (n=michele@ip-176-22.sn2.eutelia.it) |
| 08:17.18 | *** part/#storm Bracki (n=9brauer@rzdspc10.informatik.uni-hamburg.de) |
| 10:06.07 | *** join/#storm thumper (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 10:49.17 | *** join/#storm ajmitch (n=ajmitch@ubuntu/member/ajmitch) |
| 10:56.07 | *** join/#storm thumper (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 12:29.29 | *** join/#storm niemeyer (n=niemeyer@200.163.194.205) |
| 12:45.03 | *** join/#storm statik (n=emurphy@189.66.188.72.cfl.res.rr.com) |
| 13:21.51 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 13:33.20 | *** join/#storm radix (n=radix@70.91.133.157) |
| 14:16.19 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9C135.dip0.t-ipconnect.de) |
| 14:19.42 | *** join/#storm brosner (n=brian@63.150.173.39) |
| 14:21.16 | *** join/#storm seanhodges (n=sean@host81-149-197-244.in-addr.btopenworld.com) |
| 14:28.48 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9C135.dip0.t-ipconnect.de) |
| 15:21.50 | *** join/#storm sean__ (n=sean@host81-149-197-244.in-addr.btopenworld.com) |
| 15:32.17 | *** part/#storm seanhodges (n=sean@host81-149-197-244.in-addr.btopenworld.com) |
| 15:36.48 | *** join/#storm hagna (n=hagna@70.98.162.62) |
| 15:36.58 | hagna | storm does not support order by? |
| 15:37.16 | radix | hagna: it does, but there's no convenience method on Comparable for it |
| 15:37.21 | radix | wait |
| 15:37.26 | radix | order_by? it does |
| 15:37.28 | radix | I was thinking group_by |
| 15:37.36 | radix | (also I didn't mean Comparable, I meant ResultSet) |
| 15:37.38 | hagna | ohhhh yes that's right |
| 15:37.58 | radix | store.find(Foo).order_by(Foo.column) |
| 15:40.52 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 15:58.39 | *** join/#storm thumper (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 15:59.48 | weatherman | storm/zope.security-expose-attribute r174 committed by radix@twistedmatrix.com |
| 15:59.48 | weatherman | - expose __storm_object_info__, not __object_info |
| 15:59.49 | weatherman | - WITH TESTS |
| 16:03.14 | radix | Ok guys, I need some reviews on bug #141010 |
| 16:03.15 | ubot3 | Malone bug 141010 in storm "storm.zope zope.security wrapper integration is broken" [Critical,In progress] https://launchpad.net/bugs/141010 |
| 16:36.10 | aa_ | can all fields be None? |
| 16:36.36 | aa_ | it seems like they can, but not sure |
| 16:53.30 | radix | aa_: all properties default to allowing None |
| 16:53.50 | radix | aa_: but they also all accept an allow_none parameter, which you can set to False |
| 16:53.57 | aa_ | ok great |
| 16:54.16 | aa_ | my client wants yes/no/maybe :( |
| 16:55.45 | jamesh | well, an SQL NULL is more like "unknown" than "maybe" |
| 16:56.14 | jamesh | if that isn't what you want, then perhaps use an enumeration |
| 17:01.16 | aa_ | jamesh: well officially its "not recorded" |
| 17:01.26 | aa_ | but they want it for every field |
| 17:01.40 | aa_ | it's a late late feature request |
| 17:02.09 | jamesh | there are lots of different types of "not recorded" though |
| 17:02.28 | jamesh | and it can be useful to distinguish them when doing statistical analysis of data |
| 17:02.58 | aa_ | yes, but they only have one kind of not recorded |
| 17:03.40 | aa_ | like what would I use for a not-recorded in a unicode field? |
| 17:03.53 | aa_ | say if I had three types of it |
| 17:04.00 | aa_ | I would need another field I guess |
| 17:07.00 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 17:08.48 | jamesh | for surveys (as an example), something might be not recorded because the user refused to answer, the user provided an invalid answer, a person doing data entry could not decipher what was written on a form, etc |
| 17:17.02 | aa_ | right |
| 17:23.44 | *** join/#storm Key_Gena (i=lok@gateway/tor/x-94f93e6429fe510f) |
| 17:53.04 | *** join/#storm metatheorem (n=metatheo@cpe-24-169-133-231.rochester.res.rr.com) |
| 17:55.27 | *** join/#storm WebMaven (n=webmaven@nv-65-173-67-149.dhcp.embarqhsd.net) |
| 19:21.26 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 19:38.14 | *** join/#storm jukart_ (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 21:37.56 | *** join/#storm brosner (n=brian@63.150.173.39) |
| 21:47.28 | *** join/#storm thumper (n=tim@125-236-193-95.adsl.xtra.co.nz) |
| 22:25.30 | weatherman | storm/trunk r174 committed by radix@twistedmatrix.com |
| 22:25.30 | weatherman | Merge ~radix/storm/zope.security-expose-attribute [r=niemeyer,michelp] [f=141010] |
| 22:25.34 | weatherman | This fixes a minor but critical typo in the storm.zope / zope.security |
| 22:25.38 | weatherman | integration so that wrapped objects can be passed to storm methods. |
| 22:38.21 | *** join/#storm jml (n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net) |
| 22:43.03 | *** join/#storm bozzo (n=chatzill@BSN-77-50-148.dial-up.dsl.siol.net) |
| 23:01.32 | bozzo | hello! I'd need some help with storm, how to approach mapping a schema created for Hibernate's "one table per class" |
| 23:06.57 | radix | bozzo: Storm is one table per class as well. |
| 23:10.57 | bozzo | radix: how do I specify the discriminator column for the subclasses? |
| 23:13.49 | radix | bozzo: oh, maybe I understood you. I think what you're thinking is called "one table per subclass" by Hibernate. |
| 23:14.17 | radix | although I'm not totally sure. |
| 23:15.00 | bozzo | radix: yes, I was really unclear in the question. I figured out the simple stuff, but the inheritance thing is escaping me |
| 23:15.36 | radix | bozzo: as far as I can tell, "discriminator columns" in hibernate mean "a column which describes which class to instantiate to represent this row"? |
| 23:16.21 | bozzo | radix: correct, or more tipically, which table to join to get the rest of the 'row' |
| 23:16.29 | radix | bozzo: Storm doesn't have a way to return homogenous result sets. You have to specify the type of the objects you want when you query. |
| 23:16.36 | radix | bozzo: huh |
| 23:16.41 | radix | bozzo: that sounds totally different from what I just said :) |
| 23:16.44 | radix | bozzo: or at least it implies a lot more |
| 23:17.34 | radix | bozzo: we actually did implement a feature very similar to this once for Landscape, but we decided it was not worth it and very confusing :) |
| 23:18.19 | bozzo | the way I currently contemplate is mapping inheritance by containment and do all the id column dancing manually |
| 23:19.22 | radix | bozzo: that's pretty much what we do. We represent some homogenous things in our data model by adding a 'type' column to the table which is full of homogenous data, then when we fetch the object and access certain things we instantiate another object based on that type |
| 23:19.39 | radix | bozzo: and that type can either be stored in the database (in another table) or just be some simple in-memory object |
| 23:25.33 | weatherman | storm/trunk r175 committed by radix@twistedmatrix.com |
| 23:25.33 | weatherman | Merge internal storm development to trunk [a=various] [r=various] [f=various] |
| 23:25.38 | weatherman | This adds case-insensitive support to LIKE and fixes some cases where |
| 23:25.42 | weatherman | passing wrapped objects to Storm methods wouldn't work as expected. |
| 23:26.15 | bozzo | radix: is it ok to post a code snippet of what I came up with for review? |
| 23:26.47 | radix | bozzo: please put it in a pastebin or something. |
| 23:26.51 | radix | bozzo: http://rafb.net/paste/ |
| 23:30.52 | bozzo | radix: http://rafb.net/p/Xg4nhY51.html |
| 23:32.14 | radix | bozzo: not sure what you mean by "follow"; just make sure you give it the same ID whenever you instantiate an Enclosure |
| 23:32.47 | radix | bozzo: oh, actually |
| 23:33.08 | radix | bozzo: just don't give it its own ID, give it an InventoryItem_id which is a FOREIGN KEY into InventoryItem |
| 23:33.29 | radix | (and you can make that Enclosure's primary key as well) |
| 23:34.07 | radix | bozzo: other than that, the only thing that offends me is all the globals() stuff instead of looking up in a strict mapping of type IDs to classes :) |
| 23:34.15 | bozzo | radix: which of the 'it's dont need the ID |
| 23:34.47 | radix | bozzo: Enclosure. Let me rephrase |
| 23:35.31 | radix | bozzo: Rename Enclosure's id "InventoryItem_id" and make it a FOREIGN KEY to InventoryItem (id) in the schema |
| 23:35.49 | radix | although that's probably already what you're doing :) |
| 23:35.59 | bozzo | I am |
| 23:36.03 | radix | I'm just trying to respond to your "can I make this id always follow the InventoryItem's one?" |
| 23:39.14 | radix | Ok, I'm heading home for the night. |
| 23:40.02 | bozzo | radix: thanks! |
| 23:41.41 | bozzo | radix: in terms of 'following' I meant something like teaching Storm to enforce this FK for me in the object land |
| 23:59.57 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |