On Nov 21, 1:02 pm, Matt Haggard <[EMAIL PROTECTED]> wrote:
> thank you for the response. I have a few more followup questions (I am
> really a newbie to this...) :
>
> 1. Where does engine come from? Is there anyway to do what you've
> suggested with Session? If it helps, I'm using this with pylons and
> am trying to get stuff working in the controller of my app.
you can get a connection from your session by saying conn =
session.connection(). then you can use that to execute. Im assuming
youre using the Pylons tutorial, where your engine has been explicitly
associated with your Session. if not, then you'd have to say conn =
session.connection(MyMappedClass).
>
> 2. If I have to write SQL (or a pythonic version of SQL) to get info
> out of the DB, why am I even using SQL Alchemy? it seems a little
> ridiculous.
well first of all, the apply_sum() function you were trying to use
*will* work once we get around to fixing it up. this is open source
development; SA follows the philosophy of "release early, release
often" so that the toolset, while we are fairly polished at this point
and most users seem to have a decent experience, will always have some
"under construction" elements to it. the users of an open source
project are as much a part of the project's continued development as
the developers themselves, just like your stumbling upon "apply_sum()"
being broken results in trac tickets, new fixes and new test coverage
(coverage tools alone could not locate this issue since the individual
lines of code *are* covered in current unit tests).
Also, SA is an abstraction layer over SQL and DBAPI....it is designed
for people who like SQL and are familiar with its workings, who want a
toolset that eliminates most of the repetition and tedium of
generating average SQL and dealing with the mechanics of DBAPI, while
at all times providing fine-grained ability to issue literal SQL at
any point. SA is not designed to insulate the developer from SQL,
and competing toolsets that have been introduced since SA's release
are also taking the same approach.
The services SA provides (which you can read on the "intro" page and
some of the linked pages there) include: connection pooling,
abstraction from DBAPI differences, convenience features at the SQL
execution and result set level, SQL expression constructs, and finally
the ORM which is an entirely optional feature. Lots of people don't
use the ORM at all, but still find it easier to say:
table.insert().execute(col1='somevalue')
rather than:
conn = mysqldb.connect(username='scott', password='tiger', db='test')
cursor = conn.cursor()
cursor.execute("insert into mytable (col) values (%s)", ['somevalue'])
conn.commit()
conn.close()
Theres a lot more to it than that, such as having an already opened
connection available, being able to use different databases like PG
transparently, etc. this is all without ever having a Session or
Query mentioned at all - the orm package is just icing on the cake.
DBAPI is just a pain in the butt to work with directly.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
