| 00:42.44 | *** join/#storm evilaliv3 (~evilaliv3@unaffiliated/evilaliv3) |
| 02:02.55 | *** join/#storm jkakar (~jkakar@75.157.165.167) |
| 02:03.20 | *** join/#storm AzMoo (~matt@mail.cmv.com.au) |
| 02:03.25 | *** join/#storm AzMoo (~matt@unaffiliated/azmoo) |
| 02:03.48 | AzMoo | Hi guys, are there any schema migration tools for Storm, like South for Django ORM? |
| 04:38.52 | *** join/#storm infobot (~infobot@rikers.org) |
| 04:38.52 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.19 released! || Review branches: https://code.launchpad.net/storm/+activereviews || IRC logs: http://ibot.rikers.org/#storm/ || API documentation: http://people.canonical.com/~therve/storm/ |
| 04:51.25 | *** join/#storm jkakar (~jkakar@75.157.165.167) |
| 08:26.10 | *** join/#storm evilaliv3 (~evilaliv3@93-44-216-117.ip99.fastwebnet.it) |
| 10:01.52 | evilaliv3 | hi jkakar |
| 10:02.02 | evilaliv3 | i've a question for you |
| 10:02.31 | evilaliv3 | i'm iterating over a reference like this: for receivers in context.receivers: |
| 10:03.21 | evilaliv3 | and i've seen that the performance in this case are really terrible, because if i have 42 refereces i got 42 querys |
| 10:03.37 | evilaliv3 | is there a way to optimize this in STORM ? |
| 10:34.17 | *** join/#storm evilaliv3 (~evilaliv3@93-44-216-117.ip99.fastwebnet.it) |
| 12:11.50 | evilaliv3 | jkakar: ? |
| 12:42.46 | *** join/#storm jamesh_ (~james@canonical/launchpad/jamesh) |
| 12:43.03 | evilaliv3 | hey jamesh_ are you here? |
| 13:08.11 | *** join/#storm niemeyer (~niemeyer@189.35.68.58) |
| 13:08.11 | *** mode/#storm [+o niemeyer] by ChanServ |
| 13:19.48 | *** join/#storm fcorrea (~fcorrea@187.3.135.242) |
| 14:08.24 | *** join/#storm niemeyer (~niemeyer@189.35.68.58) |
| 14:08.24 | *** mode/#storm [+o niemeyer] by ChanServ |
| 14:08.59 | *** join/#storm evilaliv4 (~evilaliv3@93-44-216-117.ip99.fastwebnet.it) |
| 16:00.34 | *** join/#storm fcorrea_ (~fcorrea@187.3.135.242) |
| 16:38.56 | *** join/#storm nicedice (~nicedice@unaffiliated/nicedice) |
| 18:01.43 | *** join/#storm evilaliv3 (~evilaliv3@93-44-216-117.ip99.fastwebnet.it) |
| 18:05.54 | evilaliv3 | niemeyer: a getattr(storm_obj, "attr") seems to me to be triggering an object UPDATE also if i'm simply reading the attibute |
| 18:06.05 | evilaliv3 | do you know why this may happen ? |
| 18:11.35 | niemeyer | evilaliv3: Accessing the attribute may force a flush to resolve its value |
| 18:19.04 | evilaliv3 | mmm damn, but this cause that for each request i do, i do also a write, really really strange |
| 18:19.21 | evilaliv3 | this does not happen if a do obj.attr read |
| 18:19.37 | evilaliv3 | but if i do getattr(obj, 'attr') |
| 18:20.14 | evilaliv3 | now i'm going to try if obj.__dict__[''attr'] solves my issue |
| 19:01.03 | evilaliv3 | so, if i do not misunderstand STORM sometimes makes some commit also if not requested explicilty by the user? |
| 19:01.36 | evilaliv3 | i'm reflecting if this is good or not due to the overhead it may cause |
| 19:01.59 | evilaliv3 | in fact this transfrom read only actions in automagic commit operations |
| 19:02.20 | evilaliv3 | *write operations |
| 19:08.14 | *** join/#storm evilaliv3 (~evilaliv3@93-44-216-117.ip99.fastwebnet.it) |
| 19:12.04 | evilaliv3 | niemeyer: found my bug, i'm using a different store for each transact |
| 19:12.24 | evilaliv3 | <PROTECTED> |
| 19:26.18 | niemeyer | evilaliv3: <evilaliv3> so, if i do not misunderstand STORM sometimes makes some commit also if not requested explicilty by the user? |
| 19:26.21 | niemeyer | evilaliv3: UPDATE != commit |
| 19:26.46 | niemeyer | evilaliv3: Storm definitely does updates whenever it has to |
| 19:27.05 | niemeyer | evilaliv3: Glad to hear you've found the prolbem |
| 19:28.09 | evilaliv3 | update is not a write query to the db ? |
| 19:28.33 | evilaliv3 | is correct that to have caching i must be using the same store? |
| 19:29.01 | evilaliv3 | what succed if the application use multiple store? may happen some inconsinstency? |
| 19:29.38 | evilaliv3 | i think not in general to db model, but i don't trust completely storm implementation at the time :) |
| 20:15.53 | *** join/#storm minibota (~textual@200.30.177.46) |
| 20:55.56 | niemeyer | evilaliv3: Storm is being used by massive pieces of infrastructure for several years |
| 20:56.03 | niemeyer | evilaliv3: Launchpad, Landscape, Ubuntu One |
| 20:56.23 | niemeyer | evilaliv3: Of course, it can definitely have bugs, and most likely has |
| 20:56.30 | niemeyer | evilaliv3: But you can expect it to not be totally broken |
| 20:56.50 | niemeyer | evilaliv3: Landscape uses multiple stores |
| 20:56.59 | niemeyer | evilaliv3: In fact, that's the main reason why Storm exists at all |
| 21:06.11 | *** join/#storm milosn (~milosn@94.12.79.143) |
| 21:06.11 | *** join/#storm spidaman_____ (uid10200@gateway/web/irccloud.com/x-rxhziatjmrnlyjpm) |
| 21:06.33 | *** join/#storm m4v (~znc@ubuntu/member/m4v) |
| 21:06.39 | *** join/#storm 45PAAH7F8 (~bennett@li243-126.members.linode.com) |
| 21:06.47 | *** join/#storm yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 21:18.35 | evilaliv3 | niemeyer: i think only the sqlite part is broken |
| 21:19.13 | evilaliv3 | there are various important errors i'm going to notify and due to that i think it is not used |
| 21:19.35 | evilaliv3 | the twisted transact part is completely broken |
| 21:20.33 | evilaliv3 | and if used with multithreading with sqlite i got a lot of database is locked errors |
| 21:22.40 | *** join/#storm m4v (~znc@ubuntu/member/m4v) |
| 21:53.36 | *** join/#storm syst3mw0rm_ (~quassel@ec2-54-200-173-177.us-west-2.compute.amazonaws.com) |
| 22:06.44 | *** join/#storm niemeyer (~niemeyer@189.35.68.58) |
| 22:06.44 | *** mode/#storm [+o niemeyer] by ChanServ |
| 22:26.42 | *** join/#storm syst3mw0rm (~quassel@ec2-54-200-173-177.us-west-2.compute.amazonaws.com) |
| 22:39.08 | *** join/#storm niemeyer (~niemeyer@189.35.68.58) |
| 22:39.08 | *** mode/#storm [+o niemeyer] by ChanServ |