| 00:00.15 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 02:48.31 | *** part/#storm marianom (n=marianom@ubuntu/member/marianom) |
| 04:05.51 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:17.04 | *** join/#storm bigdog (n=scmikes@8.8.197.72) |
| 05:40.25 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 05:53.52 | *** join/#storm dobee (n=dobeee@lsfw01.lovelysystems.com) |
| 07:59.31 | *** join/#storm goschtl (n=goschtl@p5B0BF5C3.dip.t-dialin.net) |
| 08:13.06 | *** join/#storm bigdo2 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 09:41.21 | *** join/#storm goschtl (n=goschtl@p54943768.dip.t-dialin.net) |
| 09:42.20 | *** join/#storm goschtl (n=goschtl@p54943768.dip.t-dialin.net) |
| 09:49.42 | *** join/#storm harnak (n=harnak@ip-118-90-69-51.xdsl.xnet.co.nz) |
| 09:50.36 | *** join/#storm goschtl (n=goschtl@p54943768.dip.t-dialin.net) |
| 10:18.57 | *** join/#storm harnak (n=Harnak@ip-118-90-69-51.xdsl.xnet.co.nz) |
| 10:23.05 | *** join/#storm harnak (n=harnak@ip-118-90-69-51.xdsl.xnet.co.nz) |
| 11:15.05 | *** join/#storm goschtl (n=goschtl@p5B0BF5C3.dip.t-dialin.net) |
| 12:04.07 | *** join/#storm Brend (n=brendonh@218-170-228-158.dynamic.hinet.net) |
| 12:04.23 | Brend | Hola. |
| 12:04.36 | Brend | Does Storm keep a mapping of __storm_table__ -> Class somewhere public? |
| 12:41.06 | radix | Brend: it doesn't even keep one in private, IIRC |
| 12:42.04 | Brend | Yeah, there's just the __cls_info on the class I think. Fair enough. |
| 12:45.02 | *** join/#storm niemeyer (n=niemeyer@200-103-245-169.ctame705.dsl.brasiltelecom.net.br) |
| 12:45.51 | niemeyer | jamesh: ping |
| 14:10.14 | *** join/#storm marianom (n=marianom@ubuntu/member/marianom) |
| 14:11.19 | *** join/#storm mcella_ (n=mcella@ip-178-43.sn2.eutelia.it) |
| 14:17.16 | jamesh | niemeyer: pong |
| 14:17.24 | niemeyer | jamesh: Hey James |
| 14:17.36 | jamesh | hi |
| 14:17.49 | niemeyer | jamesh: Sorry for not providing details yesterday |
| 14:18.03 | jamesh | no problem |
| 14:18.10 | niemeyer | jamesh: I have some ideas I'll put up in a branch today |
| 14:18.18 | jamesh | cool. |
| 14:18.33 | niemeyer | jamesh: The basic is having a validate argument in the property |
| 14:18.40 | niemeyer | jamesh: *and* in the variable |
| 14:18.56 | niemeyer | jamesh: The property will make partial function to give the variable |
| 14:19.21 | jamesh | okay |
| 14:19.22 | niemeyer | jamesh: So that the variable knowledge is still isolated from the object |
| 14:19.33 | niemeyer | jamesh: (and the property) |
| 14:20.00 | jamesh | niemeyer: in my reply I gave the added case of updating a property while bypassing the validator |
| 14:20.24 | niemeyer | jamesh: Hmm |
| 14:20.36 | jamesh | it doesn't have to be pretty, but some of the LP code probably needs it |
| 14:20.52 | niemeyer | jamesh: Ok.. I think I see the use case |
| 14:21.16 | niemeyer | jamesh: Do you have a simple use case that could be used for justification? |
| 14:21.52 | jamesh | niemeyer: so the use case is something like this: |
| 14:23.02 | jamesh | in the bug tracker we sometimes have two objects that should have the same information (e.g. a bug in Ubuntu and a bug in Ubuntu's latest release) |
| 14:23.18 | jamesh | we want to make updates to one object fail |
| 14:23.25 | radix | simple success: [10:21] <bigdo1> radix: I used your storm lib on a mysql integration project at work. It did the job, thanks |
| 14:23.35 | jamesh | and updates to the other object change both objects |
| 14:23.50 | niemeyer | radix: Nice :) |
| 14:24.30 | niemeyer | jamesh: Right.. I assume both objects are instances of the same class |
| 14:24.42 | niemeyer | jamesh: What's used to differentiate them? |
| 14:24.42 | jamesh | niemeyer: yeah. |
| 14:25.41 | jamesh | blocking of updates on one of the objects is primarily a correctness thing |
| 14:26.46 | niemeyer | jamesh: Right.. I'm just wondering if the "it's ok to update like this" check could somehow be made inside the validator |
| 14:26.59 | niemeyer | jamesh: Do you have lots of call sites or if we come up with an alternative it'd be easy to adopt? |
| 14:27.37 | jamesh | niemeyer: only a few callsites. I intend to modify code to use whatever API we come up with |
| 14:27.52 | niemeyer | jamesh: Cool! |
| 14:28.32 | jamesh | it is pretty cool being able to mix Storm and sqlobject API together |
| 14:28.43 | niemeyer | jamesh: If we allow the validator function to modify the object, I think it'd be easy to produce the same end result |
| 14:29.06 | jamesh | it has been useful for a few cases where trying to match the sqlobject API in the compat layer would be quite difficult |
| 14:29.12 | niemeyer | jamesh: E.g. obj.attr = NowYouShouldAcceptThis(bad_value) |
| 14:29.24 | jamesh | niemeyer: that could work, yeah. |
| 14:29.44 | niemeyer | jamesh: Being able to modify the object also has an appeal in the sense that it sounds generically useful |
| 14:30.08 | niemeyer | jamesh: process-and/or-validate rather than just validate |
| 14:30.35 | niemeyer | Simple and flexible |
| 14:30.44 | jamesh | niemeyer: yeah. The sqlobject validators are objects that transform the value, possibly raising exceptions |
| 14:30.56 | niemeyer | jamesh: Oh, sweet! The same idea then |
| 14:31.18 | niemeyer | jamesh: Is there any other niceties there which we could borrow? |
| 14:31.19 | jamesh | it handles validation in both the Python -> DB case and DB -> Python case |
| 14:31.32 | jamesh | although I don't think we care about the DB -> Python case much as far as validation goes |
| 14:31.45 | jamesh | (usually it makes more sense to define a new property/variable for that) |
| 14:31.51 | niemeyer | jamesh: Hmm.. that sounds a bit like the variable feature itself |
| 14:31.57 | niemeyer | jamesh: Right |
| 14:32.59 | jamesh | niemeyer: yeah. the meat of an SQLObject column is a validator object |
| 14:33.04 | jamesh | it then lets you stack more validators on top |
| 14:33.19 | jamesh | which can get a bit confusing |
| 14:33.52 | jamesh | having just Variable and a Python -> Python validate/transform function would handle things fine. |
| 14:34.29 | niemeyer | jamesh: Nice. We can expose that Python-only validation/parsing as an easy API for application logic, but keep more involved database details to variables still |
| 14:34.42 | jamesh | yep. |
| 14:34.50 | niemeyer | radix: Makes sense? |
| 14:35.11 | radix | huh what |
| 14:35.18 | radix | I haven't been paying attention :) |
| 14:35.29 | radix | reads scrollback |
| 14:36.24 | niemeyer | radix: jamesh is looking or a validation/parsing feature.. something we considered a few times, but haven't had major needs |
| 14:37.18 | niemeyer | radix: He correctly pointed out yesterday that Property.__set__ may be bypassed by internals when setting values, and also that the Variable itself has no access to the object, so neither of them are good options for the feature |
| 14:37.30 | radix | I see |
| 14:37.34 | radix | so what's the proposed API? |
| 14:38.00 | niemeyer | radix: So the candidate API is a "validate" argument to all properties |
| 14:38.22 | niemeyer | radix: The property will wrap the function into a partial function, and pass that as a validate argument to the Variable |
| 14:38.36 | niemeyer | radix: So validation is done in the bottom layer, while still not passing object knowledge there |
| 14:39.02 | radix | niemeyer: so, you say Int(validator=thingy), and what arguments does thingy get called with? |
| 14:39.23 | jamesh | radix: (value, instance) |
| 14:39.27 | jamesh | (or the reverse) |
| 14:39.37 | radix | cool |
| 14:39.42 | niemeyer | radix: thingy(obj, value), or maybe thingy(obj, attr, value) |
| 14:39.43 | radix | that API sounds great |
| 14:39.49 | radix | I was wondering about the attr name, yeah |
| 14:40.36 | jamesh | the reverse might be better if we want to follow the usual semantics for currying/partial application |
| 14:40.50 | niemeyer | The validator will also function as a processor, in the sense that it should return the value to be used for setting the variable |
| 14:41.54 | jamesh | having the attribute name would be very useful |
| 14:42.23 | radix | niemeyer: and it only gets called when setting the attribute on an instance, right? |
| 14:42.49 | radix | well. from "user-code", as opposed to initializing values that came from a db query? |
| 14:42.56 | radix | or would it be called in both situations? |
| 14:43.13 | niemeyer | radix: Right |
| 14:43.18 | niemeyer | radix: No :-) |
| 14:43.19 | jamesh | radix: I'd want the ability to limit it to the Python -> DB code path, yes. |
| 14:43.22 | radix | ok |
| 14:43.26 | niemeyer | radix: Only Python-level |
| 14:44.06 | niemeyer | It's actually even Python => Python, since the Variable will still do Python => DB |
| 14:44.08 | jamesh | doing Python level validation of data coming out of the DB is usually not wanted and can be slow |
| 14:44.20 | radix | agreed |
| 14:44.31 | radix | niemeyer: right, ok |
| 14:44.33 | radix | niemeyer: sounds good |
| 14:44.49 | jamesh | right, what I mean is that I'd want to do validation for (Python -> Python) -> DB but not DB -> (Python -> Python) |
| 14:45.12 | niemeyer | jamesh: Agreed |
| 14:46.00 | jamesh | as stated above, sqlobject lets you do both but I think Variable handles all the use cases I've seen for the second |
| 14:46.14 | niemeyer | Cool |
| 14:54.21 | niemeyer | I'm heading to lunch |
| 14:54.31 | niemeyer | jamesh: Have a good evening! |
| 14:55.59 | jamesh | also, I'd love to get https://bugs.edge.launchpad.net/storm/+bug/206882 landed if anyone has time to review the code |
| 14:56.01 | ubot3 | Malone bug 206882 in storm "Support for prejoins in SQLObject compatibility layer" [Undecided,New] |
| 16:38.09 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 18:46.25 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 19:28.03 | *** join/#storm harnak (n=harnak@bilbo.netconcepts.com) |
| 19:56.03 | *** join/#storm oubiwann (n=oubiwann@209-181-152-150.omah.qwest.net) [NETSPLIT VICTIM] |
| 20:33.44 | niemeyer | Validators are up for review in bug #218381 |
| 20:33.46 | ubot3 | Malone bug 218381 in storm "Properties need easy value validation support" [Undecided,In progress] https://launchpad.net/bugs/218381 |
| 22:21.23 | *** join/#storm michelp_ (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 23:11.31 | *** join/#storm marianom (n=marianom@ubuntu/member/marianom) |