Re: [flask] Re: DB Migrations
- From:
- Jonas Galvez
- Date:
- 2010-10-03 @ 15:44
On Sun, Oct 3, 2010 at 4:17 AM, Michael Bayer <mike_mp@zzzcomputing.com>wrote:
> Right but, nothing is stopping you from reading expression.py. It is long
> because it's very far along the way to being fairly complete in its
> behavior, but not very hard to understand. Some of the ORM stuff,
> that's more ambitious for someone to grok from the outside, but that's why
> we keep a 6 foot firewall between the expression language and the ORM.
>
> It is totally fine you wanted to write your own SQL tool, and I hope you go
> far with it. But please don't justify it by making insinuations and lazy
> conjectures about our project.
I'm so sorry about that, that wasn't the intention at all. I really love
SQLAlchemy and I think it's the most trustworthy DB abstraction layer for
Python. I've actually used it in several off my projects.
> This is why I made an account on this list just to respond to this. You'd
> actually *consider* that, wow SQLAlchemy has so much code, it must be dog
> slow ! Do you also choose MySQL or Postgresql by counting how many lines
> of code they have ? Here's the SQLA expression language, in a much
> older/slower version than we are now, humming along just about as fast as
> Robert Brewer's micro-expression language of that time (only 300 lines of
> code! type of boasts included) http://techspot.zzzeek.org/?p=17 Those
> lines of code are so that SQLA can support as full of a SQL expression
> language as possible. Completeness has nothing to do with speed, you're
> thinking of cyclomatic complexity side effects and method call overhead.
> Our project is insanely vigilant about such things.
>
I understand. One thing I did forget to mention was that sqlwitch is by no
means as complete as SQLAlchemy. That isn't my intention either. I just want
a bare-bones approach, something with the absolute minimum to get developer
started. The most common types of commands and queries and that's it. But
once things get complex enough as to require a better library, SQLAlchemy
would be my first choice!
-- Jonas
Re: [flask] Re: DB Migrations
- From:
- kevin beckford
- Date:
- 2010-10-03 @ 13:05
> This is why I made an account on this list just to respond to this.
I find this statement, in this context, utterly incredible.
Anyway: I love the use of "with" in sqlwich although personally I
like my SQL like I like my peppermint schnapps: In the hands of
someone else.
Thus I'm an ORM fan just because i'd rather be typing python.
I do think that one would count not lines of code, but lines of code
per code path at least, there's no way that each query runs 4500 LOC.
Re: [flask] Re: DB Migrations
- From:
- Michael Bayer
- Date:
- 2010-10-03 @ 16:06
On Oct 3, 2010, at 9:05 AM, kevin beckford wrote:
>> This is why I made an account on this list just to respond to this.
>
> I find this statement, in this context, utterly incredible.
um , what part ? someone reading a thread, someone having a response to
the thead, someone needing to sign onto the list in order to respond since
they weren't already, or just "why bother telling us that detail" ? or
the incorrect grammar perhaps...
Re: [flask] Re: DB Migrations
- From:
- Jonas Galvez
- Date:
- 2010-10-03 @ 18:35
On Sun, Oct 3, 2010 at 1:06 PM, Michael Bayer <mike_mp@zzzcomputing.com>wrote:
>
> On Oct 3, 2010, at 9:05 AM, kevin beckford wrote:
>
> >> This is why I made an account on this list just to respond to this.
> >
> > I find this statement, in this context, utterly incredible.
>
> um , what part ? someone reading a thread, someone having a response to
> the thead, someone needing to sign onto the list in order to respond since
> they weren't already, or just "why bother telling us that detail" ? or
> the incorrect grammar perhaps...
>
I think he means it's incredible we managed to get SQLAlchemy's creator to
join this list.
I do hope you stay around and give Flask a try too (if you haven't already)
:)
-- Jonas
Re: [flask] Re: DB Migrations
- From:
- Jonas Galvez
- Date:
- 2010-10-03 @ 15:49
On Sun, Oct 3, 2010 at 10:05 AM, kevin beckford <chiggsy@lazyweb.ca> wrote:
> I do think that one would count not lines of code, but lines of code
> per code path at least, there's no way that each query runs 4500 LOC.
>
I didn't mean to imply that. What I mean is that SQLAlchemy is a full-blown
ORM/SQL library. It's got dozens and dozens of features sqlwitch doesn't
have, and because of that, its implementation if inevitably a little bigger
in code size. So much bigger that I felt it would be too much work to read
all of it when all I wanted was to issue a few simple statements.
That's why I wrote sqlwitch, because I really love the with statement and I
think it should be leveraged more often, and I wanted to have the option of
starting with something really small (sqlwitch) and then (if needed) move on
to a more robust library (SQLAlchemy).
-- Jonas
Re: [flask] Re: DB Migrations
- From:
- kevin beckford
- Date:
- 2010-10-03 @ 23:56
> That's why I wrote sqlwitch, because I really love the with statement and I
_We_ love the with statement. It's a simple thing, but seeing how you
used it was the final 'click' that turned it from 'something that
looks cool' to 'part of my python.' So thank you very much.
Re: [flask] Re: DB Migrations
- From:
- Michael Bayer
- Date:
- 2010-10-03 @ 16:01
On Oct 3, 2010, at 11:49 AM, Jonas Galvez wrote:
>
>
> On Sun, Oct 3, 2010 at 10:05 AM, kevin beckford <chiggsy@lazyweb.ca> wrote:
> I do think that one would count not lines of code, but lines of code
> per code path at least, there's no way that each query runs 4500 LOC.
>
> I didn't mean to imply that. What I mean is that SQLAlchemy is a
full-blown ORM/SQL library. It's got dozens and dozens of features
sqlwitch doesn't have, and because of that, its implementation if
inevitably a little bigger in code size. So much bigger that I felt it
would be too much work to read all of it when all I wanted was to issue a
few simple statements.
>
> That's why I wrote sqlwitch, because I really love the with statement
and I think it should be leveraged more often, and I wanted to have the
option of starting with something really small (sqlwitch) and then (if
needed) move on to a more robust library (SQLAlchemy).
I love the with statement too and I use it all over the place in my
projects. SQLA and Mako though support Python 2.4 + so I don't get to use
it there (we do have optional context managers in place for transaction
control though).
Re: [flask] Re: DB Migrations
- From:
- kevin beckford
- Date:
- 2010-10-03 @ 13:08
Also, SQL i do not think can be simplified to 181 lines of python. We
have the power. Let us revel in it's use.
Re: [flask] DB Migrations
- From:
- Ali Afshar
- Date:
- 2010-10-03 @ 11:50
On Sunday, October 3, 2010, Michael Bayer <mike_mp@zzzcomputing.com> wrote:
>
>
> This is why I made an account on this list just to respond to this.
Any reason is a good reason! Welcome to Flask, Michael. SQLAlchemy
remains one of the all-time great libs (IMHO).
Regards,
Ali
Re: [flask] Re: DB Migrations
- From:
- Dan Jacob
- Date:
- 2010-10-03 @ 07:32
SQLAlchemy also has a complete migrations library:
http://code.google.com/p/sqlalchemy-migrate/ and a Flask extension.
It's a proven tool and rock-solid.
The "with" syntax for handling expressions is neat though, and an
extension on top of SQLAlchemy would be a good idea.
On 3 October 2010 08:17, Michael Bayer <mike_mp@zzzcomputing.com> wrote:
> On October 2, 2010 22:10, Jonas Galvez <jonasgalvez@gmail.com> wrote:
>
>> sqlwitch is centered on the with statement. Here's what an insert with
>> SQLAlchemy's expression language looks like:
>>
>> ins = users.insert().values(name='jack', fullname='Jack Jones')
>> conn.execute(ins)
>>
>> Here's the same with sqlwitch:
>>
>> with db.insert(into='users') as obj:
>> obj.name = 'jack'
>> obj.fullname = 'Jack Jones'
>> db.execute()
>>
>> So this particular characteristic comes from my own obsession with the with
>> statement :)
>
> I'm sure you understand that the above "with" syntax is trivial to
implement on top of a SQLA construct, and you'd get the benefits of lots
of backends/DBAPIs/SQL support for free, too. Your 181 lines of code
really only needs to be about 25 or 30 tops. Then you could add one
flag to your context manager and get "RETURNING" support out of your
INSERT too.
>
>
>>
>> This design constraint makes sqlwitch use only 181 lines of code. I don't
>> know much about the internals of SQLAlchemy, but at least sql/expression.py
>> (one of many files in the whole library) has over 4500 lines of code.
>
> If you think 4500 lines is a lot, you should take a look at the SQL
specification sometime.
>
>
>> I know
>> that's no reasonable parameter to compare against(for all I know it can use
>> that much lines and still be fast),
>
>
> This is why I made an account on this list just to respond to this.
You'd actually *consider* that, wow SQLAlchemy has so much code, it must
be dog slow ! Do you also choose MySQL or Postgresql by counting how
many lines of code they have ? Here's the SQLA expression language, in
a much older/slower version than we are now, humming along just about as
fast as Robert Brewer's micro-expression language of that time (only 300
lines of code! type of boasts included) http://techspot.zzzeek.org/?p=17
Those lines of code are so that SQLA can support as full of a SQL
expression language as possible. Completeness has nothing to do with
speed, you're thinking of cyclomatic complexity side effects and method
call overhead. Our project is insanely vigilant about such things.
>
>
>> but I really like keeping things as
>> simple as possible, and in the case of a DB abstraction layer, previous
>> experience has taught me that the more you know what's going on under the
>> covers, the better off you are in the long run ;)
>
> Right but, nothing is stopping you from reading expression.py. It is
long because it's very far along the way to being fairly complete in its
behavior, but not very hard to understand. Some of the ORM stuff,
that's more ambitious for someone to grok from the outside, but that's why
we keep a 6 foot firewall between the expression language and the ORM.
>
> It is totally fine you wanted to write your own SQL tool, and I hope you
go far with it. But please don't justify it by making insinuations and
lazy conjectures about our project.
>
>
>
>
>
>