2008-5-1
| 05:26 | wmealin1 | er, hi |
| 05:26 | brosner | hello |
| 05:26 | wmealin1 | so, first Q, these may be stupid, so i'll ask |
| 05:26 | wmealin1 | and you can smack me down for why later. |
| 05:27 | wmealin1 | Company that I'm working for is looking to go to an ORM, and hopefully later re-write their god forsaken web framework in django |
| 05:27 | wmealin1 | obviously i'd like them to move to the most futureproof framework |
| 05:27 | wmealin1 | and therefore ORM |
| 05:28 | wmealin1 | have the developers given any insight on what the conditions are to "accept" SQLalchemy branch ? |
| 05:28 | brosner | ok, let's begin with there is absolutely no need for a sqlalchemy "branch or project" to be included with django imho |
| 05:29 | wmealin1 | ok, so why does this project exist ? |
| 05:29 | brosner | to simply make a declarative layer that follows django and the orm so that native sqlalchemy works inside of django |
| 05:30 | brosner | the goal is not to make django's orm better, but to give developers access to sqla without breaking code and third party apps |
| 05:30 | brosner | but since we are using sqla there will be bits that can easily improve django's orm for free |
| 05:31 | wmealin1 | so, your branch supplements the existing ORM ? |
| 05:31 | brosner | next thing, we are NOT a branch |
| 05:31 | wmealin1 | ok |
| 05:31 | wmealin1 | (btw, this would be well explained on the wiki) |
| 05:31 | brosner | sqla is NOT just an orm. its a whole database python package |
| 05:32 | brosner | in all honesty we have NOTHING to do with django other than we are mapping to it |
| 05:32 | brosner | sqlalchemy branch in django != us |
| 05:32 | brosner | :) |
| 05:32 | wmealin1 | my apologies for the term. |
| 05:32 | brosner | what exactly do you think you will benefit from sqla? |
| 05:33 | wmealin1 sighs | |
| 05:33 | wmealin1 | ok |
| 05:33 | wmealin1 | do I see it as "replacing mysql" rather than "replacing the orm" |
| 05:33 | wmealin1 | you still need a database though |
| 05:34 | brosner | what? |
| 05:34 | brosner | oh hrm |
| 05:34 | brosner | i think i wasn't clear |
| 05:34 | brosner | sqla is a python database abstraction layer and not just an orm ;) |
| 05:34 | brosner | you dont replace mysql with sqla |
| 05:35 | wmealin1 | essentially what i'm asking is.. where does this slot in .. in django ? |
| 05:35 | wmealin1 | as a developer, do i not notice it ? |
| 05:36 | brosner | right |
| 05:36 | brosner | everything should work like regular old django |
| 05:36 | wmealin1 | ok.. so next question |
| 05:36 | brosner | under the hood there may be a bit of a difference |
| 05:36 | brosner | like the sql it produces, etc... |
| 05:36 | wmealin1 | so it sits between the ORM and database itself. |
| 05:37 | brosner | basically we use our own QuerySet |
| 05:37 | brosner | so calls made on it are translated to sqla |
| 05:38 | brosner | MyModel.objects.all() == session.query(MyModel).all() |
| 05:38 | wmealin1 | I see. |
| 05:38 | wmealin1 | ok, well that answers my question then. |
| 05:39 | wmealin1 | no inherit difference on the users end, therefore I can factor out sql-alchemy if the django orm will consume it sometime later, at least from the applications point of view. |
| 05:40 | brosner | so are you going from sqla to django? |
| 05:40 | wmealin1 | negative. |
| 05:40 | wmealin1 | i'm going for raw sql, to something else. |
| 05:40 | brosner | using session.query(MyModel).all() would just work too. so ideally if you use this project you are really using it for sqla and not a better django orm |
| 05:41 | brosner | some nice things you get for free though is multi-db support and increased backend database support |
| 05:42 | wmealin1 has to bring together postgresql, durus, db4 and ini files. | |
| 05:42 | brosner | well i actually need to head out... doing a big server move. but we are here alot so drop by anytime |
| 05:43 | wmealin1 | right. |