[sqlalchemy] Re: func.max()
On 12/9/06, jose [EMAIL PROTECTED] wrote:
Thank you Michael for your explanation.
Since I can do (on sqlalchemy), the same thing in more than one ways,
I'm very confused and I would like ask you, about
Constructing SQL Queries via _table objects_ or _mapper classes_
Seems to me that *table object* is more flexible than *classe*s to
construct a query,
but I wonder what the difference between those and when/why using one or
another...
I'll try to explain.
c = select(users)
With this method, what you get back when you call c.execute() is a
ResultProxy. You then would call result.fetchall() to get a list of
RowProxy objects, which you can then access in several ways:
row[0] # Returns the value of the first column in the database table
row['name'] # Returns the value of the name column, regardless of
its position
row.address# Ditto for the address column
This is just like doing result = cursor.fetchall(); for row in
result: ... from any DBAPI module, except that the rows have some
slightly nicer ways to access them.
See http://www.sqlalchemy.org/docs/sqlconstruction.myt#sql_select_resultproxy
for more details about this usage.
c = session.query(Users)
Using this approach, when you call c.select(), you'll get a list (not
a ResultProxy, but a plain old Python list) of User instances, each of
which has its attributes already filled-in and modifiable. Thus:
result = c.select_by(name='Robin')
u = result[0]
print u.name # Prints Robin
u.name = 'Robin Munn' # This marks the row as dirty
session.flush() # This flushes all dirty rows, thus doing the
appropriate UPDATE statement
Notice how by simply setting the name attribute, I've caused an
UPDATE statement to be prepared. (It won't be actually *run* until you
call session.flush()). If you were using the c = select(users)
method of constructing SQL queries, you'd have needed to run the
UPDATE statement by hand, by doing:
update(users.c.name=='Robin').execute(name='Robin Munn')
(Or by doing connection.execute('UPDATE users SET name ...') and so
on. As with the SELECT statements, SQLAlchemy doesn't force you to use
its features. If you want to issue raw SQL, you can.)
The advantage of using SQLAlchemy's mapped objects, therefore, can be
seen in the fact that you didn't have to run the UPDATE statements
yourself. Nor did you have to keep track of which objects have been
changed (are dirty). SQLAlchemy does all that for you. By contrast,
when you use the bare c = select(users) approach (selecting against
the table object, not against the mapped class) then what you get are
plain old database rows, that do *not* track updates and so on --
which means you have to issue your UPDATE statements (and your INSERT
and DELETE statements) by hand.
http://www.sqlalchemy.org/docs/datamapping.myt#datamapping_query will
tell you more about issuing queries against mapped objects.
--
Robin Munn
[EMAIL PROTECTED]
GPG key 0x4543D577
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: func.max()
it should be noted that SQLAlchemy is really *two* separate software packages in one. one part of SA is, a tool that allows you to build SQL queries through python expressions. I usually call it the SQL construction part of SA. you issue SQL statements and get back result sets, which act like dictionaries. the other application is called the ORM (object relational mapper). this application is built on top of the other application, i.e. the SQL construction tool. All the code for this application lives within the package sqlalchemy.orm, although when you import sqlalchemy you get all the names from this application in the same namespace. The SQL Construction tool knows *nothing at all* about the ORM. the job of the ORM is to map user-defined Python classes to database table rows. it creates its own SQL statements, with just a little bit of guidance from you, and processes the results into Python classes. So they are really two different things. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: func.max()
Robin Munn wrote:
On 12/9/06, jose [EMAIL PROTECTED] wrote:
Thank you Michael for your explanation.
Since I can do (on sqlalchemy), the same thing in more than one ways,
I'm very confused and I would like ask you, about
Constructing SQL Queries via _table objects_ or _mapper classes_
Seems to me that *table object* is more flexible than *classe*s to
construct a query,
but I wonder what the difference between those and when/why using one or
another...
I'll try to explain.
c = select(users)
With this method, what you get back when you call c.execute() is a
ResultProxy. You then would call result.fetchall() to get a list of
RowProxy objects, which you can then access in several ways:
row[0] # Returns the value of the first column in the database table
row['name'] # Returns the value of the name column, regardless of
its position
row.address# Ditto for the address column
This is just like doing result = cursor.fetchall(); for row in
result: ... from any DBAPI module, except that the rows have some
slightly nicer ways to access them.
See http://www.sqlalchemy.org/docs/sqlconstruction.myt#sql_select_resultproxy
for more details about this usage.
c = session.query(Users)
Using this approach, when you call c.select(), you'll get a list (not
a ResultProxy, but a plain old Python list) of User instances, each of
which has its attributes already filled-in and modifiable. Thus:
result = c.select_by(name='Robin')
u = result[0]
print u.name # Prints Robin
u.name = 'Robin Munn' # This marks the row as dirty
session.flush() # This flushes all dirty rows, thus doing the
appropriate UPDATE statement
Notice how by simply setting the name attribute, I've caused an
UPDATE statement to be prepared. (It won't be actually *run* until you
call session.flush()). If you were using the c = select(users)
method of constructing SQL queries, you'd have needed to run the
UPDATE statement by hand, by doing:
update(users.c.name=='Robin').execute(name='Robin Munn')
(Or by doing connection.execute('UPDATE users SET name ...') and so
on. As with the SELECT statements, SQLAlchemy doesn't force you to use
its features. If you want to issue raw SQL, you can.)
The advantage of using SQLAlchemy's mapped objects, therefore, can be
seen in the fact that you didn't have to run the UPDATE statements
yourself. Nor did you have to keep track of which objects have been
changed (are dirty). SQLAlchemy does all that for you. By contrast,
when you use the bare c = select(users) approach (selecting against
the table object, not against the mapped class) then what you get are
plain old database rows, that do *not* track updates and so on --
which means you have to issue your UPDATE statements (and your INSERT
and DELETE statements) by hand.
http://www.sqlalchemy.org/docs/datamapping.myt#datamapping_query will
tell you more about issuing queries against mapped objects.
Your explanation is perfect, Robin.
Now I see, it is preferrable to use mapped classes if after the query I
want to other operations like update, delete, insert.
Otherwise it seems to me that object tables is more powerful than mapped
objects to construct stand alone queries.
Is it true or only a my personal sensation?
jo
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Proposal: session identity_map no longer weak referencing
when SA was first released, someone immediately suggested that the identity map of Session be weak referencing, which appeared to be an obvious improvement, so that you could load as many objects as you want from the session and whatever you didnt use would just go away. but now it appears that the more intuitive operation for a Session is that things that get loaded into it, stay there, until you say otherwise. If I got what yoy mean, I think I had suggested something like that myself... but it was back in SA 0.1 days, when there was no explicit Session. But are you saying that doing sth like a = MappedObject() session.save(a) del a would prevent 'a' from being saved when flushing the session? In SA 0.3.1 it seems to stay in it. Or it's just a matter of changed attributes, something like a = query.get_by(id=x) a.attribute = 4 del a ? In both cases, I think the strongly referenced behaviour is OK. If it's in a session, I want an object to be tracked whatsoever, unless I explicitly remove it. -- Alan Franzoni [EMAIL PROTECTED] - Togli .xyz dalla mia email per contattarmi. Remove .xyz from my address in order to contact me. - GPG Key Fingerprint (Key ID = FE068F3E): 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: ORM and metaclasses init problem
Sorry, I had checked the docs but not the FAQ. I opened a ticket as well, feel free to close it. I think it should be stated in a more clear in way in the docs, though, since it's an unpredictable behaviour. But was that behaviour present in 0.1.x? I feel a bit estranged about never noticing that. Anyway, I don't see what's the possible drawback of calling the original __init__ . As long as no explicit construction parametr or keyword is required (which was a requirement back in 0.1.x, I think), it shouldn't create any problem, and should be more adherent to sqlalchemy's philosophy of 'not forcing any kind of programming style'. Thank you anyway! -- Alan Franzoni [EMAIL PROTECTED] - Togli .xyz dalla mia email per contattarmi. Remove .xyz from my address in order to contact me. - GPG Key Fingerprint (Key ID = FE068F3E): 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
