| 01:51.54 | *** join/#storm jkakar (n=jkakar@S0106001ee57a879c.vc.shawcable.net) |
| 02:22.14 | *** join/#storm shaunm (n=shaunm@c-98-212-133-244.hsd1.il.comcast.net) |
| 02:28.34 | *** join/#storm r4ck_Work (n=vrduhube@189-46-202-198.dsl.telesp.net.br) |
| 04:18.09 | *** join/#storm shaunm (n=shaunm@c-98-212-133-244.hsd1.il.comcast.net) [NETSPLIT VICTIM] |
| 04:18.48 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) [NETSPLIT VICTIM] |
| 04:18.48 | *** join/#storm rockstar (n=rockstar@canonical/launchpad/rockstar) [NETSPLIT VICTIM] |
| 04:18.48 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) [NETSPLIT VICTIM] |
| 05:12.13 | *** join/#storm jukart (n=jukart@d91-128-122-124.cust.tele2.at) |
| 05:50.06 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 07:54.52 | *** join/#storm goschtl (n=goschtl@p5B0BFB72.dip.t-dialin.net) |
| 09:48.49 | *** join/#storm akm1 (n=akm1@122.166.39.10) |
| 09:49.50 | akm1 | Hi, how to retrieve individual columns from a table using store.find ?...by default its retrieving all columns... |
| 09:55.39 | jml | akm1: store.find(...).values(Thing.column1, Thing.column2) |
| 09:55.52 | jml | akm1: storm.canonical.com/Tutorial has more details, iirc. |
| 09:59.00 | akm1 | jml, in the release notes of .13, i saw "Expressions can be passed to Store.find() as well as classes. This makes it possible to request individual columns from a table,computed expressions or aggregates." |
| 09:59.16 | akm1 | jml, how to do this ? |
| 10:40.41 | *** join/#storm r4ck_Work (n=vrduhube@201-92-217-21.dsl.telesp.net.br) |
| 11:03.57 | *** join/#storm noodles775 (n=miken@f053065111.adsl.alicedsl.de) |
| 11:07.39 | noodles775 | Hi all, I'm wondering how I go about using order_by without returning the attribute that I'm ordering by? If it was a column I assume it would be fine as long as the column was in the from clause, but if it's not, should I explicitly define a Comparable? |
| 11:07.44 | noodles775 | (I'm dealing with a rank) |
| 11:14.17 | noodles775 | Forget that... it's not a storm issue: psycopg2.ProgrammingError: |
| 11:14.17 | noodles775 | for SELECT DISTINCT, ORDER BY expressions must appear in select list |
| 11:48.08 | *** join/#storm vvinet (n=vince@modemcable188.10-70-69.static.videotron.ca) |
| 12:00.55 | *** join/#storm niemeyer (n=niemeyer@212.183.221.191.dyn.user.ono.com) |
| 12:04.07 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 12:25.27 | *** join/#storm munga (n=munga@81.194.35.9) |
| 12:57.26 | *** join/#storm keppla (n=keppla@i577B36C8.versanet.de) |
| 13:37.22 | keppla | hi all |
| 13:38.53 | therve | hello |
| 13:40.00 | keppla | i have a question concering transactions and mysql |
| 13:40.18 | keppla | (in storm context, of course) |
| 13:40.40 | therve | ok |
| 13:41.17 | keppla | i have an object a, i make an assignment a.field = "x" |
| 13:41.36 | keppla | and that seems to go directly to the database |
| 13:41.52 | keppla | it does not get reverted by store.rollback() |
| 13:42.11 | keppla | do i have to take special steps to make transactions work? |
| 13:42.19 | keppla | (using mysql5.0) |
| 13:42.41 | therve | keppla: what backend are you using? |
| 13:43.09 | therve | keppla: you need to use InnoDB to support transactions |
| 13:43.22 | keppla | ah, cool. sec please |
| 13:44.05 | keppla | ah, yes, i am currently using MyIsam |
| 13:44.06 | keppla | thanks |
| 13:44.14 | therve | no problem |
| 13:44.15 | keppla | gonna switch |
| 14:13.30 | *** join/#storm r4ck_Work (n=vrduhube@201-92-217-21.dsl.telesp.net.br) |
| 14:35.12 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 14:52.09 | *** join/#storm r4ck_Work (n=vrduhube@201-92-217-21.dsl.telesp.net.br) |
| 14:58.16 | *** part/#storm keppla (n=keppla@i577B36C8.versanet.de) |
| 15:01.48 | *** join/#storm bigdog1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 16:03.08 | *** join/#storm keppla (n=keppla@i577B36C8.versanet.de) |
| 16:03.19 | keppla | hi all |
| 16:03.35 | keppla | another question, more of a style thing i guess |
| 16:04.02 | keppla | i am trying to organize my model |
| 16:04.49 | keppla | currently i have some classes, and each class gets its own file |
| 16:04.55 | keppla | because they are very long |
| 16:05.18 | keppla | that leads to the problem, that it is hard to make finders inside this classes |
| 16:05.25 | keppla | because the depend on each other |
| 16:05.31 | keppla | as an example: |
| 16:05.48 | keppla | <PROTECTED> |
| 16:05.48 | keppla | <PROTECTED> |
| 16:05.49 | keppla | <PROTECTED> |
| 16:05.49 | keppla | <PROTECTED> |
| 16:05.49 | keppla | <PROTECTED> |
| 16:05.49 | keppla | <PROTECTED> |
| 16:05.51 | keppla | <PROTECTED> |
| 16:06.18 | keppla | the import statements are inside the funtion, because in import time, the other model classes are not yet importable |
| 16:07.03 | mzz | perhaps more of a #python question, but you can in practice get away with circular imports if you import the module (not its contents) and don't access the contents at import time |
| 16:07.25 | mzz | not sure if I'd go for that myself though. |
| 16:07.52 | mzz | I'd probably go for a longer module myself, unless your classes are really insanely huge |
| 16:07.54 | keppla | you are right that this import-stuff is more python, but my question goes more in the direction of how to organise a storm model |
| 16:08.00 | keppla | hm |
| 16:08.08 | mzz | (how huge is huge?) |
| 16:08.12 | keppla | ok, not exactly "insanely huge" |
| 16:08.17 | keppla | but (sec please)... |
| 16:08.53 | keppla | about 1000 lines now |
| 16:09.05 | keppla | (the complete model) |
| 16:09.28 | mzz | I usually start worrying if my modules exceed 1000 lines |
| 16:09.30 | keppla | i guess, i just dont like big files |
| 16:09.38 | keppla | that would be the case right now ;) |
| 16:11.07 | keppla | ok, but as a first result: this is not something were there is a big agreement in the community on how to organize the files? |
| 16:11.29 | mzz | I'm not sure if there's anything storm-specific to be aware of here |
| 16:11.36 | keppla | ok, thanks |
| 16:11.45 | mzz | not a heavy storm user though, so definitely wait for a second opinion |
| 16:19.19 | *** join/#storm shaunm (n=shaunm@proxyserver.wolfram.com) |
| 16:21.42 | *** join/#storm r4ck_Work (n=vrduhube@201-26-124-141.dsl.telesp.net.br) |
| 16:52.10 | *** join/#storm Full-8733780 (n=vrduhube@201-26-124-141.dsl.telesp.net.br) |
| 17:07.01 | *** part/#storm keppla (n=keppla@i577B36C8.versanet.de) |
| 17:10.48 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 17:13.14 | jkakar | mzz: Hey, thanks for helping out! It's great to see. :) |
| 17:14.48 | jkakar | mzz: One hint about that in the future: keppla's card_levels property should be defined as a ReferenceSet, I believe. Also, there is a Storm base class that can be inherited from; it makes it possible to use strings, to avoid problems with circulars imports. So "CardLevel.id" instead of CardLevel.id could be used, for example. |
| 17:15.16 | mzz | ahh, yeah, I should've remembered that storm-specific bit |
| 17:15.35 | mzz | I wasn't really paying attention to the storm bits in the pasted code |
| 17:15.43 | mzz | but I should've remembered about the base class + strings |
| 17:34.09 | *** join/#storm jukart (n=jukart@d91-128-122-124.cust.tele2.at) |
| 18:10.21 | *** join/#storm artista_frustrad (n=artista_@201.25.169.73) |
| 18:23.25 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 18:25.08 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 19:43.41 | *** join/#storm artista_frustrad (n=artista_@201.25.170.88) |