Re: [sqlalchemy] Re: find the table columns
On Thu, 2010-01-14 at 05:29 -0800, Kosu wrote:
try this:
user.__table__.c.keys()
should work
Kos Rafal
AttributeError: 'User' object has no attribute '__table__'
thanks anyway
On 14 Sty, 11:39, laurent FRANCOIS lau.franc...@worldonline.fr
wrote:
Hello everybody
Let's say I have a
table_user= Table('user', blablabla...)
class User(object): pass
mapper(User, table-user)
Let's say I have an ORM object: user = User(name='FOO')
With that user I would like to get all the attribut columns like
with table_user.c.keys().
Must be easy no?
Thanks
Laurent FRANCOIS
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Configuring an existing session
Hi,
I use a global session instance to work with my DB, so all module
import it and use it. But at some point I sometimes need to
reconfigure the engine to use another DB. I want to reconfigure the
existing instance so other modules can still use the same session
object to work with the DB.
can I safely change the bind attribute of an existing scoped session
or is there any things to be taken care of before I do it ? (like
closing active connections in the pool maybe ?)
I've tried to use configure to reset the engine, but it doesn't work
(the bind attribute remain unchanged) :
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy import create_engine
Session = scoped_session(sessionmaker())
Session.configure(bind=create_engine('sqlite:///tmp/db1'))
Session.bind
Engine(sqlite:///tmp/db1)
Session.configure(bind=create_engine('sqlite:///tmp/db2'))
Session.bind
Engine(sqlite:///tmp/db1) --- same !
So, it this safe :
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy import create_engine
Session = scoped_session(sessionmaker())
Session.configure(bind=create_engine('sqlite:///tmp/db1'))
Session.bind
Engine(sqlite:///tmp/db1)
Session.bind = create_engine('sqlite:///tmp/db2')
Session.bind
Engine(sqlite:///tmp/db2)
Thanks
Tarek
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] sqlsoup and partitioned db's
sqlsoup explicitly used a scoped session, but i would like to use a shardedsession for my horizontally partitioned db. is this supported at all? thanks. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: find the table columns
On Thu, Jan 21, 2010 at 9:08 AM, laurent FRANCOIS
lau.franc...@worldonline.fr wrote:
On Thu, 2010-01-14 at 05:29 -0800, Kosu wrote:
try this:
user.__table__.c.keys()
should work
Kos Rafal
AttributeError: 'User' object has no attribute '__table__'
from sqlalchemy import *
metadata = MetaData()
user = Table('user', metadata, Column('name', String))
user.c.keys()
['name']
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Configuring an existing session
Tarek Ziadé wrote:
Hi,
I use a global session instance to work with my DB, so all module
import it and use it. But at some point I sometimes need to
reconfigure the engine to use another DB. I want to reconfigure the
existing instance so other modules can still use the same session
object to work with the DB.
can I safely change the bind attribute of an existing scoped session
or is there any things to be taken care of before I do it ? (like
closing active connections in the pool maybe ?)
I've tried to use configure to reset the engine, but it doesn't work
(the bind attribute remain unchanged) :
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy import create_engine
Session = scoped_session(sessionmaker())
Session.configure(bind=create_engine('sqlite:///tmp/db1'))
Session.bind
Engine(sqlite:///tmp/db1)
add Session.remove() here. configure() only works for the
not-yet-created session.
Otherwise, you can just say Session.bind = create_engine(...) which will
only change the current session.
configure() is more so that various parts of an applications startup can
add their elements to a global session config.
Session.configure(bind=create_engine('sqlite:///tmp/db2'))
Session.bind
Engine(sqlite:///tmp/db1) --- same !
So, it this safe :
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy import create_engine
Session = scoped_session(sessionmaker())
Session.configure(bind=create_engine('sqlite:///tmp/db1'))
Session.bind
Engine(sqlite:///tmp/db1)
Session.bind = create_engine('sqlite:///tmp/db2')
Session.bind
Engine(sqlite:///tmp/db2)
Thanks
Tarek
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] sqlsoup and partitioned db's
razamatan wrote: sqlsoup explicitly used a scoped session, but i would like to use a shardedsession for my horizontally partitioned db. is this supported at all? thanks. sure in 0.5 just swap out the Session global in sqlsoup. in 0.6 you can set a session on a per-SqlSoup basis: http://www.sqlalchemy.org/docs/06/reference/ext/sqlsoup.html?#sessions-transations-and-application-integration -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] LIMIT function behavior
The limit() function behaves in a way that is possibly unexpected: If you ask sqlalchemy to query limit(3) where a join is involved, for example, and 2 of the top-3 are actually the same primary key, sqlalchemy gets the 3 results, throws out the duplicate and your query size ends up as 2. This gives the impression there are no more matches because you asked for 3 and got only 2, when in fact you may have hundreds of possible rows. Right off, I can't think of an elegant solution to this behavior. Certainly sqlalchemy could *detect* the problem after the fact and re- request a greater limit, but that is ugly hackish and results in multiple trips to the database, sqla wouldn't know how many to re- request, etc... sqlalchemy could request DISTINCT results, but I'm not sure how easily that could be implemented or what it may break. Interested if anyone has an elegant solution? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] LIMIT function behavior
Kent wrote: The limit() function behaves in a way that is possibly unexpected: If you ask sqlalchemy to query limit(3) where a join is involved, for example, and 2 of the top-3 are actually the same primary key, sqlalchemy gets the 3 results, throws out the duplicate and your query size ends up as 2. This gives the impression there are no more matches because you asked for 3 and got only 2, when in fact you may have hundreds of possible rows. Right off, I can't think of an elegant solution to this behavior. Certainly sqlalchemy could *detect* the problem after the fact and re- request a greater limit, but that is ugly hackish and results in multiple trips to the database, sqla wouldn't know how many to re- request, etc... sqlalchemy could request DISTINCT results, but I'm not sure how easily that could be implemented or what it may break. Interested if anyone has an elegant solution? this is a natural effect of placing LIMIT on a query with a join. To limit the inner results only, use query.limit(N).from_self().join(...) which will apply the LIMIT to a subquery. SQLAlchemy's eager loading feature also does this subquery effect as needed. from_self() was added so that users could have access to this functionality in a more generic way. the Query remains explicit about join() and the fact that you're working with SQL - so from_self() is a necessary explicit step too. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: LIMIT function behavior
Unfortunately, in the case I noticed this happen, the join needs to be applied first since the filter's where clause and the order by both depend on the joined tables. Don't think your solution is helpful in that case, but informative nonetheless. I can imagine a DISTINCT helping (I am using oracle, so limit is implemented with an outer select and rownum), but the minute I put a DISTINCT in the outer SELECT, the order by in the inner select is destroyed. (Also, I couldn't figure out how to get sqlalchemy to put the distinct in the outer select -- at the same select that uses ROWNUM = :N in Oracle -- perhaps for good reason, since it destroys the order by!) This case was somewhat contrived and may never present as a live problem anyway. Thank you for your informative input and speedy response. - Kent On Jan 21, 12:00 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: The limit() function behaves in a way that is possibly unexpected: If you ask sqlalchemy to query limit(3) where a join is involved, for example, and 2 of the top-3 are actually the same primary key, sqlalchemy gets the 3 results, throws out the duplicate and your query size ends up as 2. This gives the impression there are no more matches because you asked for 3 and got only 2, when in fact you may have hundreds of possible rows. Right off, I can't think of an elegant solution to this behavior. Certainly sqlalchemy could *detect* the problem after the fact and re- request a greater limit, but that is ugly hackish and results in multiple trips to the database, sqla wouldn't know how many to re- request, etc... sqlalchemy could request DISTINCT results, but I'm not sure how easily that could be implemented or what it may break. Interested if anyone has an elegant solution? this is a natural effect of placing LIMIT on a query with a join. To limit the inner results only, use query.limit(N).from_self().join(...) which will apply the LIMIT to a subquery. SQLAlchemy's eager loading feature also does this subquery effect as needed. from_self() was added so that users could have access to this functionality in a more generic way. the Query remains explicit about join() and the fact that you're working with SQL - so from_self() is a necessary explicit step too. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: LIMIT function behavior
Kent wrote: Unfortunately, in the case I noticed this happen, the join needs to be applied first since the filter's where clause and the order by both depend on the joined tables. Don't think your solution is helpful in that case, but informative nonetheless. I can imagine a DISTINCT helping (I am using oracle, so limit is implemented with an outer select and rownum), but the minute I put a DISTINCT in the outer SELECT, the order by in the inner select is destroyed. (Also, I couldn't figure out how to get sqlalchemy to put the distinct in the outer select -- at the same select that uses ROWNUM = :N in Oracle -- perhaps for good reason, since it destroys the order by!) This case was somewhat contrived and may never present as a live problem anyway. Thank you for your informative input and speedy response. another solution, though it performs more poorly from a SQL perspective, is to use any() or has() instead of a join. its much easier to write as an expression, and it generates an EXISTS subquery. the count of primary rows is unaffected. - Kent On Jan 21, 12:00 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: The limit() function behaves in a way that is possibly unexpected: If you ask sqlalchemy to query limit(3) where a join is involved, for example, and 2 of the top-3 are actually the same primary key, sqlalchemy gets the 3 results, throws out the duplicate and your query size ends up as 2. This gives the impression there are no more matches because you asked for 3 and got only 2, when in fact you may have hundreds of possible rows. Right off, I can't think of an elegant solution to this behavior. Certainly sqlalchemy could *detect* the problem after the fact and re- request a greater limit, but that is ugly hackish and results in multiple trips to the database, sqla wouldn't know how many to re- request, etc... sqlalchemy could request DISTINCT results, but I'm not sure how easily that could be implemented or what it may break. Interested if anyone has an elegant solution? this is a natural effect of placing LIMIT on a query with a join. To limit the inner results only, use query.limit(N).from_self().join(...) which will apply the LIMIT to a subquery. SQLAlchemy's eager loading feature also does this subquery effect as needed. from_self() was added so that users could have access to this functionality in a more generic way. the Query remains explicit about join() and the fact that you're working with SQL - so from_self() is a necessary explicit step too. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
