| 03:32.33 | *** join/#storm danilos (~danilo@cable-178-148-38-107.dynamic.sbb.rs) |
| 03:32.33 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 04:46.21 | *** join/#storm wallyworld (~quassel@27-33-46-253.static.tpgi.com.au) |
| 06:18.06 | *** join/#storm jkakar (~jkakar@243.Red-83-60-98.dynamicIP.rima-tde.net) |
| 07:25.53 | *** join/#storm zmijunkie (~sascha@pd95b6fd9.dip0.t-ipconnect.de) |
| 07:37.38 | *** join/#storm sdehaan (~sdehaan@41-135-61-47.dsl.mweb.co.za) |
| 07:59.52 | *** join/#storm esteve (~quassel@cli-5b7ee22f.bcn.adamo.es) |
| 08:00.19 | *** join/#storm stub (~stub@125.24.135.233.adsl.dynamic.totbb.net) |
| 08:00.19 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 08:06.03 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 09:28.56 | *** join/#storm zmijunkie (~sascha@pd95b6fd9.dip0.t-ipconnect.de) |
| 09:40.56 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 10:52.08 | *** join/#storm sdehaan (~sdehaan@41-132-42-180.dsl.mweb.co.za) |
| 12:10.28 | *** join/#storm sidnei (~sidnei@201-35-178-226.cslce701.dsl.brasiltelecom.net.br) |
| 12:32.48 | *** join/#storm niemeyer (~niemeyer@189-10-155-52.pltce701.dsl.brasiltelecom.net.br) |
| 13:10.40 | *** join/#storm jkakar_ (~jkakar@131.Red-88-5-210.dynamicIP.rima-tde.net) |
| 14:17.42 | *** join/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 16:34.18 | *** join/#storm webmaven (~webmaven@97.65.119.2) |
| 16:52.08 | *** join/#storm jdobrien (~john@50-88-19-25.res.bhn.net) |
| 16:52.44 | jdobrien | is there a clean way to test your storm classes to make sure all the properties match when you get an object from the db? |
| 16:53.08 | jdobrien | just a basic test but I don't want to list all the properties to compare them |
| 17:01.59 | marienz | I'm not sure I understand the question |
| 17:02.37 | marienz | you mean you want to test one of your objects is healthy after retrieving it from the db? |
| 17:02.45 | jdobrien | marienz, yes. |
| 17:02.46 | marienz | I can't think of a way of automating that that'd be useful |
| 17:03.25 | marienz | that is: if you automated that I think you'd really be testing storm, not your code, which doesn't seem useful |
| 17:04.13 | jdobrien | I'm not trying to test storm. |
| 17:04.40 | jdobrien | marienz, python will let me do a test where I set a value to a variable that isn't even a storm property |
| 17:05.07 | marienz | yes. |
| 17:05.39 | jdobrien | marienz, I don't know of a good way to avoid that |
| 17:05.51 | marienz | so you could automatically check all the properties storm knows about made it back out ok, but that doesn't seem useful since you're really testing storm. |
| 17:06.04 | jdobrien | marienz, true |
| 17:06.13 | marienz | and you can probably check that there aren't any non-storm properties set on the object *before* putting it in the db, but I don't think that's a good test. |
| 17:06.19 | jdobrien | marienz, know of a way I can prevent new attributes in the class? |
| 17:06.37 | jdobrien | __slots__ doesn't seem to work in this case |
| 17:06.52 | marienz | __slots__ isn't meant for this, although I suspect it could work |
| 17:07.19 | jdobrien | I just don't want my test to allow typos |
| 17:07.25 | marienz | I'd just write the longwinded test you're considering (confirming that the object retrieved from the db has all properties set it should have) |
| 17:07.42 | marienz | since I wouldn't want to make it impossible for my object to have non-storm attributes |
| 17:07.48 | jdobrien | yeah i was trying to avoid the long winded part :) |
| 17:08.01 | marienz | well, it's not *that* longwinded |
| 17:08.18 | marienz | you could just list the attribute names and confirm they're all set to something (just test getattr()-ing them works) |
| 17:08.18 | vvinet | well __slots__ *is* the way to prevent unwanted attributes |
| 17:08.35 | marienz | no, __slots__ is a (somewhat nasty) optimization |
| 17:09.00 | marienz | *depending* on __slots__ making assigning other attributes impossible is pretty nasty, and may not even hold in non-cpython pythons |
| 17:09.21 | marienz | let's see if the documentation backs me up on this |
| 17:09.29 | vvinet | I agree... it's about optimization |
| 17:09.59 | jkakar | jdobrien: Hi! |
| 17:10.02 | vvinet | but the other option is to use __setattr__, no? |
| 17:10.11 | jdobrien | jkakar, hi there |
| 17:10.18 | jkakar | jdobrien: If I understand what you want, you can use Storms internal object information to do something... |
| 17:10.23 | jkakar | jdobrien: Lemme write some code, one sec. |
| 17:10.30 | jdobrien | vvinet, I'm not trying to get too fancy |
| 17:11.09 | jdobrien | jkakar, it would be nice to be able to make a storm object less-dynamic |
| 17:11.10 | jdobrien | :) |
| 17:11.38 | marienz | jkakar: sure, but that only suffices if he just wants to forbid non-storm attributes outright. What he wants to check is that he didn't accidentally set a regular python attribute that storm was meant to store in the db for him. |
| 17:11.56 | marienz | he doesn't want to confirm that the attributes storm *does* know about made it out ok |
| 17:12.27 | marienz | so by using storm's internal object information he's depending on the same information he wants to test is correct |
| 17:12.48 | jdobrien | I should be able to assume a storm property set, will come back out of the db. |
| 17:12.54 | marienz | exactly |
| 17:13.00 | jkakar | jdobrien: Yes, you can. You don't need to test that. |
| 17:13.27 | marienz | so I don't see how you can automate this, unless you want to forbid or explicitly whitelist any non-storm attributes the thing might grow |
| 17:13.41 | jdobrien | jkakar, but if I to avoid obj.mispelled_storm_property = u"Hi" I'm not sure of a good way |
| 17:13.53 | jdobrien | without being long winded |
| 17:14.27 | jdobrien | I could probably poke the PropertyPublisher |
| 17:15.06 | jkakar | jdobrien: http://paste.ubuntu.com/593224/ |
| 17:15.09 | marienz | you have to decide what you really want to test here, that everything made it out of the db correctly, or if the thing has any non-storm attributes |
| 17:15.16 | jkakar | jdobrien: A better way is with the object's ClassInfo... |
| 17:16.06 | jdobrien | jkakar, I noticed obj.__dict__ will include the accidentally added properties too |
| 17:17.12 | jkakar | jdobrien: Another way to do it is something like this: http://paste.ubuntu.com/593226/ |
| 17:17.44 | jkakar | jdobrien: Yes, it will. The last example is just to demonstrate that one method is to kill the object and get Storm to reload it. |
| 17:18.04 | jdobrien | jkakar, that's what i was doing, but it was getting long and repatative |
| 17:18.06 | marienz | I'd use that second approach, with an added assertion that the object was indeed actually reloaded |
| 17:18.13 | jkakar | jdobrien: Then make assertions to verify that everything you expect to be there actually is (since you have a new instance you'll find out whether you set something accidentally). |
| 17:18.24 | jkakar | marienz: Right, exactly. |
| 17:18.26 | marienz | (not sure if that can be done any better than by intentionally setting an untracked attribute and confirming it's no longer there after the reload) |
| 17:18.46 | marienz | oh wait, store.invalidate |
| 17:18.51 | marienz | I guess that covers that sufficiently |
| 17:18.59 | jkakar | jdobrien: Does this issue come up very often... I don't know what you're doing, but I can't help but wonder if it isn't overly defensive...? |
| 17:20.02 | jdobrien | jkakar, no not often, I figured I'm not the first one to touch storm and there would be an easy way to make sure it doesn't happen. I suppose i'm testing the nature of python |
| 17:20.11 | jkakar | jdobrien: Yeah. :/ |
| 17:21.04 | jdobrien | jkakar, in times past, we've just set the properties, added to the db and moved on to the next test |
| 17:21.23 | jdobrien | jkakar, which IMO, is a pretty lame test |
| 17:22.00 | jkakar | jdobrien: Are you talking about a test specific to instantiating (or otherwise setting up) an instance? |
| 17:22.04 | marienz | I still think that "make sure loaded object has all expected attributes" is a better enhancement to that test than "make sure no untracked attributes exist" or "make sure all attributes storm knows about are present". |
| 17:22.28 | jkakar | jdobrien: I find that my tests inevitably involve store.find, which means a query is run and the database is returning results... ie, you know the data made a roundtrip. |
| 17:22.42 | marienz | nods |
| 17:22.45 | jkakar | marienz: +1. |
| 17:23.14 | marienz | as those last two are really either testing storm or making assumptions about your implementation |
| 17:23.15 | jdobrien | marienz, true...I guess the long winded way is the way to go :( |
| 17:23.29 | marienz | while the former is testing your actual desired behavior |
| 17:23.58 | jkakar | jdobrien: What about leaving it untested and dealing with it on a case-by-case basis...? |
| 17:24.13 | jdobrien | jkakar, it will come up as the testing continues |
| 17:24.17 | jkakar | jdobrien: Or testing the actual behaviour that breaks because the wrong attribute was set (or the right one wasn't set)...? |
| 17:26.17 | jdobrien | jkakar, I'll probably stick with that |
| 17:27.47 | jkakar | jdobrien: :) |
| 17:29.30 | jdobrien | come to think of it...why the heck do i have these properties without a test case yet :) |
| 17:29.45 | jdobrien | goes back to his 500 line branch rule |
| 17:29.58 | jkakar | Hehe |
| 17:30.38 | jdobrien | jkakar, how's barcelona, must be beautiful this time of year |
| 17:30.58 | jkakar | jdobrien: It's super awesome. :) |
| 17:31.18 | jkakar | jdobrien: Last week the weather changed... all of a sudden it's sunny and 20â°C everyday. |
| 17:31.33 | jkakar | jdobrien: Meanwhile, Vancouver (where I'm from) is having the coldest spring in recorded history. :/ |
| 17:31.49 | jdobrien | hehe |
| 17:32.14 | jdobrien | it's very warm here in flordida |
| 17:32.14 | jkakar | jdobrien: How are things with you? |
| 17:32.19 | jkakar | Yeah, I bet. :) |
| 17:32.33 | jdobrien | jkakar, pretty good. U1 is keeping me busy |
| 17:32.54 | jkakar | jdobrien: Nice. :) |
| 17:45.20 | jdobrien | jkakar, one more storm question |
| 17:46.00 | jkakar | jdobrien: 'sup? |
| 17:46.14 | jdobrien | jkakar, I would like to store a dict as a json string in a property, but would like a custom storm property which does the work. |
| 17:46.29 | jdobrien | jkakar, is there any documentation or examples of this around? |
| 17:46.55 | jkakar | jdobrien: I have a branch you can review. :) |
| 17:47.09 | jdobrien | haha |
| 17:47.28 | jkakar | jdobrien: Actually, no, I need to fix it an land it. |
| 17:47.30 | jkakar | jdobrien: https://bugs.edge.launchpad.net/storm/+bug/726799 |
| 17:47.31 | _mup_ | Bug #726799: It would be nice to have a JSON property <Storm:In Progress by jkakar> < https://launchpad.net/bugs/726799 > |
| 17:48.07 | jkakar | jdobrien: Yes, there's a custom property. I have to fix the issue Thomas mentions in his review and get it re-reviewed and landed. |
| 17:48.25 | jkakar | jdobrien: In the meantime, you could copy the code from that branch into yours (ugh, ugly). |
| 17:48.34 | jdobrien | I'll take a look |
| 17:48.45 | jdobrien | it will at least give me some ideas |
| 17:48.58 | jkakar | jdobrien: I'll sort out the branch soonishly, since I want to get it landed... and obviously its useful. |
| 17:49.13 | jkakar | jdobrien: Uhm, if you want the same behaviour but want to wait for the branch you can use Pickle instead of JSON as a property. |
| 17:49.25 | jkakar | jdobrien: The behaviour will be the same, but the serialization format will be different (obviously). |
| 17:50.43 | jdobrien | oh i didn't see this one EncodedValueVariable |
| 17:53.48 | jdobrien | I have the luxury of importing json :) |
| 17:54.08 | jkakar | jdobrien: :) |
| 19:00.50 | *** part/#storm magmatt (~Matt@74-92-245-181-Utah.hfc.comcastbusiness.net) |
| 19:53.30 | *** join/#storm webmaven (~webmaven@97.65.119.2) |
| 22:31.47 | *** join/#storm wallyworld_ (~quassel@27-33-46-253.static.tpgi.com.au) |