| 02:08.10 | *** join/#storm jml (n=jml@203-113-250-169-static.TAS.netspace.net.au) |
| 03:10.02 | *** join/#storm jml (n=jml@203-113-250-169-static.TAS.netspace.net.au) |
| 03:11.07 | *** join/#storm statik (n=emurphy@189.66.188.72.cfl.res.rr.com) |
| 03:38.31 | *** join/#storm pyCube (n=jmayfiel@ip70-162-117-219.ph.ph.cox.net) |
| 03:54.17 | *** join/#storm bigdo2 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 04:24.17 | *** join/#storm dobee (n=dobeee@194.183.146.186) |
| 04:47.24 | *** join/#storm pyCube (n=jmayfiel@ip70-162-117-219.ph.ph.cox.net) |
| 05:08.32 | *** join/#storm jml (n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net) |
| 05:15.07 | *** join/#storm Key_Gena95 (i=lok@gateway/tor/x-73f42468d3d0d04f) |
| 05:36.11 | *** part/#storm MFen (n=cdodt@demo.thesoftworld.com) |
| 05:38.12 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 06:48.22 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9A774.dip0.t-ipconnect.de) |
| 07:11.20 | *** join/#storm mcella (n=michele@ip-176-22.sn2.eutelia.it) |
| 07:41.58 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9A774.dip0.t-ipconnect.de) |
| 08:21.15 | dobee | hi all, a question regarding arrays in postgresql |
| 08:21.27 | dobee | how can i describe this comparison in storm |
| 08:21.28 | dobee | select * from books |
| 08:21.29 | dobee | where comment_authors @> '{members.utvlAOrjCpYT}' |
| 08:21.51 | dobee | comment_authors is a storm List aka postgres Array |
| 08:21.57 | dobee | @> means contains |
| 09:08.06 | jamesh | dobee: I am not sure whether Storm has support for that operator |
| 09:08.39 | jamesh | dobee: that said, you could always do something like store.find(class, SQL("TableName.comment_authors @> '{members.utvlAOrjCpYT}'")) |
| 09:25.37 | *** join/#storm Key_Gena95 (i=lok@gateway/tor/x-d85a1222504bcd14) |
| 09:43.59 | *** join/#storm jukart_ (n=jukart@194.183.146.181) |
| 09:55.21 | dobee | jamesh: thx for the reply, yes i've already done that, thought there is a better way in storm, because of the qoting of the value |
| 09:59.39 | jamesh | dobee: sure. I am not saying that the SQL() method is the best -- just that Storm's expression compilation system probably doesn't have that operator right now |
| 10:01.00 | jamesh | dobee: if you normalised your schema to use a separate "comment author" table to represent the relationship, things would be a bit clearer |
| 10:02.03 | dobee | jamesh: yes i know, but performance is poorer with normalized tables |
| 12:00.10 | *** join/#storm djfroofy (n=drew@atl190.turner.com) |
| 12:20.02 | *** join/#storm niemeyer (n=niemeyer@200-140-230-150.ctame705.dsl.brasiltelecom.net.br) |
| 13:23.41 | *** join/#storm mcella (n=michele@ip-176-22.sn2.eutelia.it) |
| 15:36.19 | jrydberg | i'm used to Axiom. how hard would it be for me to adjust to Storm? |
| 15:36.54 | radix | jrydberg: depends what you want to do |
| 15:37.15 | jrydberg | the reason I'm considering Storm is the support for MySQL |
| 15:37.31 | radix | jrydberg: ok, so if you're dealing with remote databases, there is a significant difference especially in the context of Twisted |
| 15:37.45 | jrydberg | i am |
| 15:37.50 | radix | jrydberg: axiom blocks because sqlite databases are fast and don't require traversing the network |
| 15:38.25 | radix | jrydberg: but once you start using it with a remote database, queries could take significantly longer, not just because of network time but also because other users may be connected and performing queries |
| 15:38.49 | *** join/#storm desmaj (n=user@d65h163.public.uconn.edu) |
| 15:38.53 | jrydberg | where "it" refers to Axiom ? |
| 15:39.05 | radix | jrydberg: hmm, I guess that was vague |
| 15:39.14 | radix | axiom doesn't even support remote databases |
| 15:39.20 | jrydberg | That I know. |
| 15:39.30 | radix | so what I meant was "once you start using a remote database with a blocking API" |
| 15:39.42 | jrydberg | radix: But do you see any problem using Storm within a Twisted environment? |
| 15:40.12 | radix | jrydberg: I don't see a problem using Storm within Twisted (I've done it), but I *do* see a problem with using a remote database (with a blocking API) in a Twisted environment |
| 15:40.31 | radix | jrydberg: it depends what kind of application this is, though, and how long you're willing to block for query results |
| 15:40.41 | jrydberg | Lets run Storm on twisted.enterprise.adbapi :) |
| 15:40.56 | radix | right, except then Storm's API would need to change too |
| 15:41.01 | jrydberg | mmm. |
| 15:41.21 | radix | and you really don't want "foo.bar" where 'bar' is described as Integer to return a Deferred :-) |
| 15:41.37 | jrydberg | I'm writing a quite user interactive application, so delays would be considered harmfull |
| 15:41.45 | radix | in other words, Storm is not asynchronous |
| 15:42.02 | jrydberg | I've figured that out. Was joking regarding adbapi. |
| 15:42.10 | radix | so yeah |
| 15:42.31 | radix | generally, people use lots of threads when using storm with a remote database |
| 15:42.48 | jrydberg | It is probably better to use adbapi then, directly |
| 15:42.56 | radix | well |
| 15:43.01 | radix | I wouldn't say so :) |
| 15:43.34 | radix | but it depends; if you have very very simple interactions with the database, adbapi may be good enough |
| 15:43.39 | jrydberg | I don't want to introduce threading into my Nevow+Athena application |
| 15:43.45 | radix | but adbapi is such a thin layer that it's often really terrible. |
| 15:43.46 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 15:43.51 | radix | well, adbapi uses threads :_) |
| 15:44.01 | radix | But I see what you mean - you don't want to write the threaded code yourself. |
| 15:44.01 | jrydberg | sure, but underneath my layer |
| 15:44.54 | radix | and of course there are also always multiple processes :-) |
| 15:45.01 | jrydberg | Is there a reason why you did choose not to work on Axiom ? |
| 15:45.19 | radix | You mean, add remote database support to axiom? |
| 15:45.21 | jrydberg | Yes. |
| 15:45.37 | jrydberg | The schema management part of Axiom was considered bad? |
| 15:46.00 | jrydberg | I can see that being a problem if a lot of processes try to manage the schema at the same time |
| 15:46.02 | radix | Well, there was a lot of stuff like that that got in the way, and it wasn't factored to allow us to add the remote database support very easily. |
| 15:46.32 | radix | However, we have had several conversations with the Axiom guys and there is a possibility that Storm and Axiom will cooperate in some way in the future. |
| 15:46.50 | jrydberg | license issues aside then. |
| 15:46.52 | radix | For example, Axiom may use Storm for its low level parts, like query construction, transaction management, and so forth. |
| 15:46.58 | radix | license issues had nothing to do with it, indeed. |
| 15:47.04 | radix | rather, there were no license issues. :) |
| 15:47.33 | jrydberg | Axiom is under MIT (IIRC) and Storm under LGPL |
| 15:47.37 | radix | yes. |
| 15:48.37 | jrydberg | The reason I want to use a remote database is to be able to move the application to multiple processes and/or multiple machines. |
| 15:49.01 | radix | You should talk to the Divmod guys about their ideas about scaling Axiom-using applications. |
| 15:49.37 | jrydberg | I see. |
| 15:58.27 | jrydberg | i wonder if you could use Apache as a load-balancer/proxy, and several Nevow+Axiom/storm processes servering requests |
| 15:59.49 | radix | ...what? |
| 16:00.06 | radix | I mean, yes, sure, but how is that related to the database? |
| 16:00.16 | jrydberg | you would not have to thread your applicaton |
| 16:00.21 | jrydberg | instead you run it in several processes |
| 16:00.49 | radix | so you mean, using CGI or FCGI or SCGI? sure. |
| 16:00.59 | jamesh | jrydberg: for most python web apps, it is best to run as many backends as there are CPUs |
| 16:01.08 | jamesh | and thread each backend if they require it |
| 16:02.08 | radix | I did mention multi-processes earlier :) |
| 16:02.45 | jamesh | I'm saying that it usually isn't worth having more processes and processors |
| 16:03.17 | jamesh | if you can make sure each process is as busy running Python code as possible (either through threads or non-blocking APIs) |
| 16:03.33 | jamesh | that should have been "processes than processors" |
| 17:19.51 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 17:21.39 | *** join/#storm brosner (n=brian@63.150.173.39) |
| 17:24.30 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 18:00.52 | *** join/#storm EnTeQuAk (n=EnTeQuAk@87.185.167.116) |
| 18:17.25 | jrydberg | jamesh: i suggested running sveral python processes because of the blocking API |
| 18:35.36 | *** join/#storm jukart_ (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 19:43.49 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 19:58.45 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 23:03.00 | *** join/#storm jml_ (n=jml@203-113-250-169-static.TAS.netspace.net.au) |
| 23:58.06 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |