| 03:26.37 | *** join/#storm wallyworld (~quassel@27-33-46-253.static.tpgi.com.au) |
| 04:57.24 | *** join/#storm lfactor (~loki@ppp162-220.static.internode.on.net) |
| 05:03.34 | lfactor | can anyone discuss the pros/cons of storm in relation to sqlalchemy and what to go for from a simple/clean/easy point of view. Power isn't as important. Mixing sql and orm is. |
| 05:54.28 | jamesh | lfactor: I haven't used sqlalchemy much, but I might be able to answer some of your questions |
| 06:21.04 | lfactor | jamesh, Any main reasons you went for storm over it? |
| 06:21.25 | lfactor | and an orm in general over dbapi? |
| 06:22.28 | jamesh | lfactor: I first started using Storm with Launchpad. Previously we'd been using a modified version of sqlobject, and Storm had a number of benefits over that. |
| 06:23.28 | jamesh | lfactor: (1) a cleaner code base with less badly defined behaviour, (2) better handling of multiple database connections, (3) it could generate some queries that sqlobject couldn't. |
| 06:24.08 | jamesh | lfactor: niemeyer (the person who started developing Storm) was working on Landscape, which was previously using sqlalchemy. |
| 06:24.18 | lfactor | ahh ok |
| 06:24.39 | jamesh | I understand there were some correctness issues that led to him working on Storm, but I don't think those affect current versions of sqlalchemy. |
| 06:24.56 | lfactor | ok |
| 06:25.42 | jamesh | As to why we went with an ORM rather than plain db-api, have you seen the size of the Launchpad code base? :) |
| 06:25.52 | lfactor | so any hints on a how to choose between the two now? :) Try both and see? I'm currently using psycopg2 directly and i've just been looking at some form libs, which all sit on various orm toolkits |
| 06:26.13 | lfactor | jamesh, so you think it's easier/simpler with orm? vs plain? |
| 06:26.56 | jamesh | lfactor: yes. That said, it is always worth remembering that you are using a relational database and not an OO database. |
| 06:27.09 | jamesh | it is very easy to write slow apps with an ORM if you forget |
| 06:27.48 | lfactor | yeah, thus why i have avoided ORM so far, i'm quite comfortable in sql, and pretty anti OO :) Lisp > C++/java :) |
| 06:28.23 | lfactor | i'm just hoping a light/clean ORM might make the code smaller and more readable |
| 06:29.15 | jamesh | e.g. if you have a many to one relationship, it is very easy to write code that lists the first table and then gets the corresponding record from the other table and end up doing N queries. |
| 06:29.49 | jamesh | While Storm will let you do that, it will also let you do it in a single query returning pairs of records. |
| 06:30.03 | lfactor | yeah, at the moment my storage model isn't very relational, it's basically mapping csv files to tables |
| 06:30.37 | lfactor | a user imports a csv file, and says which cols are what role in the app |
| 06:31.14 | lfactor | which becomes a table |
| 06:31.24 | lfactor | there are optional and required cols |
| 06:31.43 | lfactor | i'm contemplating changing this so they are all in a single table with an extra col as a key |
| 06:31.52 | lfactor | i.e models instead of model_1, model_2 etc |
| 06:32.23 | lfactor | can storm cope with quite dynamic reflection like this? |
| 06:33.32 | jamesh | Storm is designed to work with static DB schemas: you define classes to represent the tables in your database, with instances of those classes representing the rows in the table. |
| 06:33.56 | jamesh | That said, given Python's dynamic nature there is nothing stopping you from dynamically building those classes. |
| 06:34.11 | jamesh | It isn't a design I'd pick though ... |
| 06:36.20 | lfactor | yeah, i suspected that might be the case |
| 06:38.03 | lfactor | Is there an reflection mechanism where you can say, reflect these [tables] and it builds classes for you for each matched table? It just looks like you define a lot of classes where you already know what all the info is, i.e it's text type and called toast |
| 06:38.15 | jamesh | no. |
| 06:38.32 | jamesh | In general, you'll build some application logic into the table classes. |
| 06:39.23 | lfactor | ahh, so you end up with things like triggers/aspects etc? ok. |
| 06:39.54 | jamesh | well, you might add a constructor to the class to help with creating new rows in the table |
| 06:40.22 | jamesh | and sometimes there isn't a one to one mapping between the database column types and what you want to use in Storm |
| 06:40.34 | lfactor | fair point |
| 06:41.13 | jamesh | for example, Launchpad uses integer columns to represent enumerated values. There is a Storm column type used to map those integers to and from the Python representation of those enumeration values |
| 06:41.58 | lfactor | cool, sounds handy |
| 06:44.12 | jamesh | or in another case, for most of our projects we store timestamps with PostgreSQL's "timestamp without time zone" type. We have a Storm property type to add a UTC time zone to those datetime objects when bringing them in to Python, and convert datetime values to UTC when sending to the DB |
| 06:44.55 | jamesh | (while PostgreSQL has a "timestamp with time zone" type, that doesn't actually store a time zone: it just converts the value to/from local time when you read/write it |
| 06:44.56 | jamesh | ) |
| 06:46.36 | lfactor | makes sense as well :) Thanks for the hints, i'll look into it. I might try a test app with storm, sqlalchemy and dbapi. |
| 08:30.18 | *** join/#storm fcorrea (~fcorrea@187.3.33.106) |
| 09:11.50 | *** join/#storm zmijunkie_ (~sascha@i59F5DA62.versanet.de) |
| 09:42.21 | *** join/#storm fcorrea (~fcorrea@187.3.33.106) |
| 10:16.07 | *** join/#storm keppla (~keppla@i577B1F6A.versanet.de) |
| 11:25.37 | *** join/#storm wallyworld (~quassel@27-33-46-253.static.tpgi.com.au) |
| 11:38.35 | *** join/#storm sidnei (~sidnei@189.30.217.33) |
| 11:49.41 | *** join/#storm keppla1 (~keppla@i577B3E39.versanet.de) |
| 12:17.35 | *** join/#storm fcorrea (~fcorrea@187.3.31.9) |
| 12:31.27 | *** join/#storm jdobrien (~john@24.18.88.184.cfl.res.rr.com) |
| 13:12.50 | *** join/#storm jkakar (~jkakar@conference/ubuntudevelopersummit/x-mnrjpihsxhnqvdhs) |
| 13:21.02 | *** join/#storm gary_poster (~anonymous@99-98-191-175.lightspeed.rlghnc.sbcglobal.net) |
| 13:25.21 | *** join/#storm danilos (~danilo@conference/ubuntudevelopersummit/x-rzxujaoraayszvzb) |
| 13:25.21 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 13:33.48 | *** join/#storm sidnei (~sidnei@200-203-11-169.cslce701.dsl.brasiltelecom.net.br) |
| 14:02.55 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 18:11.05 | *** join/#storm zmijunkie (~sascha@i59F5DA62.versanet.de) |
| 19:05.56 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 19:21.06 | *** join/#storm jkakar (~jkakar@conference/ubuntudevelopersummit/x-mgsdfkqsowqrtrgg) |
| 20:54.58 | *** join/#storm niemeyer (~niemeyer@71.16.235.2) |
| 21:10.28 | *** join/#storm danilos (~danilo@conference/ubuntudevelopersummit/x-vonffbiovpnvfeod) |
| 21:10.28 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 22:02.49 | *** join/#storm fcorrea (~fcorrea@187.3.33.106) |