[sqlalchemy] Re: SQL error for mapped select (new in version 0.4) on PostgreSQL
Thanks a lot! The solution is so simple that I feel a little
embarassed...
On 16 Okt., 18:15, Michael Bayer [EMAIL PROTECTED] wrote:
On Oct 16, 2007, at 10:45 AM, klaus wrote:
The only thing that I could find out about the reason is that in
engine/base.py (1290)
context.column_labels
contains the wrong entries. It should contain something like
{..., 'table_column': 'table_column', ...}.
In the case above, however, it contains
{..., 'table_column': 'column', 'column': 'column', ...}.
(That is, it contains two items for each column, but the values are
'column' instead of 'table_column'.)
After that, I got lost. These values are generated by the postgres
driver. But I could not find where it takes its input from the Alias
object to generate something different than for the Table object.
that is exactly correct, and was one of two issues present in 0.4.
both issues, one of which occurs in 0.3 and 0.4 and the other just in
0.4 (though its hiding in 0.3 to some degree as well) originate from
two distinct name confusions that arise because you're using the name
of the table as the name of the alias. If you name the alias
something other than test then all issues go away.
so one issue was a hardcoded notion of bind parameter names used in
the ORM by query.get(), which also is used for a many-to-one lazyload
- it used the label of the column which in this case is test_id,
and conflicted with the existing test_id name (the compiler would
rename the param as test_id_1 but the Query object wasn't tracking
that). So 0.3 now generates a random name whereas 0.4 uses
anonymous bind parameters now (which are like random bind param
names except they are compile-time generated in a deterministic
fashion).
second issue is that the column_labels dictionary was being populated
with column labels from all selects embedded in the statement, not
just the top level one, so again the test_id column at the top
level conflicted with the embedded id column. since compilation
maintains a stack of select objects, the fix is easy as it means we
only operate when the stack is only one select object deep (i.e. its
the outermost select).
0.3 rev 3624 and 0.4 rev 3625
--~--~-~--~~~---~--~~
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] Storing DB engine in session
I've been struggling with this problem for a long time now and will
appreciate any help.
I'm using Oracle and pass users/passwords to access the database.
uri = 'oracle://' + config.get('sqlalchemy_conf.webuser', '') + ':' +
config.get('sqlalchemy_conf.webpassword', '') + '@' + bd_location
engine = create_engine(uri)
meta.bind = engine
Here's how it should work: every time the user logs in, SA creates a
new engine with his log/pass or uses the one that was already opened
and then uses it.
How do i keep the engine (or any other connection identifier) in the
Pylons session (can't think of any other way), so user can pass it to
the create_session?
I was trying to assign engine variable to the Pylons session, but it
fails.
What happens now is the new user logs in an all the users start using
the engine he created.
I'm pretty sure the way I'm doing things (unique log/pass for
connection) is fairly uncommon, but still that's the way I have to do
it for database security reasons. And my guess will be I'm not alone
with such an issue.
--~--~-~--~~~---~--~~
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: Connecting to a Microsoft Access Database
On Oct 16, 11:13 pm, Eddie [EMAIL PROTECTED] wrote: Having problems all day connecting and tried various apps just in case... is there anyway I could get someone to zip and host this really quick? Error * PROPFIND request failed on '/sqlalchemy/trunk' PROPFIND of '/ sqlalchemy/trunk': could not connect to server (http:// svn.sqlalchemy.org) Connect you through a proxy server ? --~--~-~--~~~---~--~~ 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: Bug (?) in combined 1:n:1 + m:n relation mapping
On Oct 16, 7:42 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Oct 16, 2007, at 1:30 PM, [EMAIL PROTECTED] wrote:
Am I really supposed to save/flush/clear/query my objects to get the
correct mappings?
Or is this a bug?
the advised pattern here is the
association object pattern described in the docs:
http://www.sqlalchemy.org/docs/04/
mappers.html#advdatamapping_relation_patterns_association
Ah, great. Thank you for your advice!
Using the association proxy
http://www.sqlalchemy.org/docs/04/plugins.html#plugins_associationproxy
I can also easily access the entities without explicitly using the
association:
u1 = User(test user 1)
e1 = Event(test event 1)
u1.events.append(e1) # association automatically created
u2 = User(test user 2)
e2 = Event(test event 2)
p2 = Participation(user=u2, event=e2, status=42) # explicit creation
of the association
Modified code for classes and mappers:
from sqlalchemy.ext.associationproxy import association_proxy
class User(object):
def __init__(self, name=None):
self.name = name
events = association_proxy('participations', 'event',
creator=lambda e: Participation(event=e))
class Event(object):
def __init__(self, title=None):
self.title = title
users = association_proxy('participations', 'user', creator=lambda
u: Participation(user=u))
class Participation(object):
def __init__(self, event=None, user=None, status=0):
self.event = event
self.user = user
self.status = status
mapper(User, user_table,
properties=dict(
participations=relation(Participation, backref='user'),
)
)
mapper(Participation, participation_table,
properties=dict(
user=relation(User, backref='participations')
)
)
mapper(Event, event_table,
properties=dict(
participations=relation(Participation, backref='event'),
)
)
--~--~-~--~~~---~--~~
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: Bug (?) in combined 1:n:1 + m:n relation mapping
On Oct 17, 12:21 pm, Thomas Wittek [EMAIL PROTECTED] wrote: mapper(Participation, participation_table, properties=dict( user=relation(User, backref='participations') ) ) Should be: mapper(Participation, participation_table) --~--~-~--~~~---~--~~ 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: Storing DB engine in session
Hi, Here's how it should work: every time the user logs in, SA creates a new engine with his log/pass or uses the one that was already opened and then uses it. Unless something has changed recently, this pattern is not particularly supported. Still, you could probably get it working with bound sessions. If the engine doesn't exist in the users, session, create the engine and save in the session. Don't know why the Pylons session save was failing, perhaps it doesn't allow arbitrary Python objects. You could keep your own dictionary, keyed on (username, password) tuples and avoid sessions altogether. Paul --~--~-~--~~~---~--~~ 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: Storing DB engine in session
Thanks a lot, Paul. Great point, works just great. That pretty much solved the issue. log_dic log_typle = (session['login'], session['password']) if not log_dic.has_key((log_typle)): engine = create_engine(uri) log_dic[log_typle] = engine else: engine = log_dic[(session['login'], session['password'])] Does this create new connection with the same name or start using the existing one? I'm almost 100% that latter, just making sure. Right now I'm binding meta to the engine, which obviosly makes all the tables work with the last engine plugged in What'll be your advice for this matter. The most obvious way i see is using Contextual Session. This way I'll have to add Session = scoped_session(sessionmaker(autoflush=True, transactional=True, bind=current_user_engine)) But I'll have to rewrite all the SQL statements so that they'll start running using sessions. select([func.count(*)], from_obj=[sell_table]).sess.execute() What'll be your best practice advice on this one? On Oct 17, 3:35 pm, Paul Johnston [EMAIL PROTECTED] wrote: Hi, Here's how it should work: every time the user logs in, SA creates a new engine with his log/pass or uses the one that was already opened and then uses it. Unless something has changed recently, this pattern is not particularly supported. Still, you could probably get it working with bound sessions. If the engine doesn't exist in the users, session, create the engine and save in the session. Don't know why the Pylons session save was failing, perhaps it doesn't allow arbitrary Python objects. You could keep your own dictionary, keyed on (username, password) tuples and avoid sessions altogether. Paul --~--~-~--~~~---~--~~ 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: SQL error for mapped select (new in version 0.4) on PostgreSQL
On Oct 17, 2007, at 4:07 AM, klaus wrote: Thanks a lot! The solution is so simple that I feel a little embarassed... im embarrased that bug's been present for so long ! --~--~-~--~~~---~--~~ 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] Check object existence into a session
How I can chek if a orm class is in a session ? --~--~-~--~~~---~--~~ 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: Check object existence into a session
On Oct 17, 2007, at 11:31 AM, Expo wrote: How I can chek if a orm class is in a session ? the session supports __contains__() . Details on session attributes are at http://www.sqlalchemy.org/docs/04/ session.html#unitofwork_using_attributes . --~--~-~--~~~---~--~~ 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] SQLAlchemy 0.4.0 Released
Hey list - I'm very happy to announce that we've put out 0.4.0 final. Thanks to all the contributors as well as all the beta testers who have helped us move through six beta releases, just to make sure we've got everything right (or as much right as we can). For those still working with 0.3, its time to upgrade ! :) Lots of folks have already done it and it's not so hard. I think this is the most well documented and easy to use SQLAlchemy yet, and its definitely the fastest by a wide margin...many kinds of operations are 50% faster and the large majority of applications should be at least 20-30% faster. We now have hotspot profiling tests as part of our testsuite so that performance-reducing changes immediately raise red flags (and of course, performance-increasing changes unleash a shower of balloons). Of course, 0.4 is a lot more than just an internal refactoring release - the public facing side also shifts the paradigms up another notch or two. The Whats New document (http://www.sqlalchemy.org/trac/ wiki/WhatsNewIn04 ) has been tracking all the enhancements and changes. The emphasis is on reduced complexity and increased flexibility, including a very consistent Query object as well as a generative select() construct, far better integration of explicit transactions with engines and sessions, and mappers that are much smarter about multi-table and inheritance mappings. We've also addressed a lot of the framework integration confusion and produced patterns and helpers that standardize web framework integration..not as plugins but as core features. The changelog documents 0.4 on a beta-by-beta basis. Big changes since 0.4.0beta6 include an experimental Sybase driver, as well as a new in_() syntax which standardizes on being passed a list rather than *args (i.e. in_([1,2,3]) instead of in_(1,2,3)). The old way still works of course but is deprecated. 0.4 download: http://www.sqlalchemy.org/download.html documentation/migration overview (worth a read): http:// www.sqlalchemy.org/docs/04/intro.html - mike --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4.0 Released
..coincidentally released on the self-same day when I am finally taking the wraps off 0.4.0 for a spin on a new project. Congrats on this huge release, everybody! On 10/17/07, Michael Bayer [EMAIL PROTECTED] wrote: Hey list - I'm very happy to announce that we've put out 0.4.0 final. Thanks to all the contributors as well as all the beta testers who have helped us move through six beta releases, just to make sure we've got everything right (or as much right as we can). For those still working with 0.3, its time to upgrade ! :) Lots of folks have already done it and it's not so hard. I think this is the most well documented and easy to use SQLAlchemy yet, and its definitely the fastest by a wide margin...many kinds of operations are 50% faster and the large majority of applications should be at least 20-30% faster. We now have hotspot profiling tests as part of our testsuite so that performance-reducing changes immediately raise red flags (and of course, performance-increasing changes unleash a shower of balloons). Of course, 0.4 is a lot more than just an internal refactoring release - the public facing side also shifts the paradigms up another notch or two. The Whats New document (http://www.sqlalchemy.org/trac/ wiki/WhatsNewIn04 ) has been tracking all the enhancements and changes. The emphasis is on reduced complexity and increased flexibility, including a very consistent Query object as well as a generative select() construct, far better integration of explicit transactions with engines and sessions, and mappers that are much smarter about multi-table and inheritance mappings. We've also addressed a lot of the framework integration confusion and produced patterns and helpers that standardize web framework integration..not as plugins but as core features. The changelog documents 0.4 on a beta-by-beta basis. Big changes since 0.4.0beta6 include an experimental Sybase driver, as well as a new in_() syntax which standardizes on being passed a list rather than *args (i.e. in_([1,2,3]) instead of in_(1,2,3)). The old way still works of course but is deprecated. 0.4 download: http://www.sqlalchemy.org/download.html documentation/migration overview (worth a read): http:// www.sqlalchemy.org/docs/04/intro.html - mike --~--~-~--~~~---~--~~ 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: SQLAlchemy 0.4.0 Released
Am Mittwoch, 17. Oktober 2007 21:40 schrieb Michael Bayer: Hey list - I'm very happy to announce that we've put out 0.4.0 final. Thanks to all the contributors as well as all the beta testers who have helped us move through six beta releases, just to make sure we've got everything right (or as much right as we can). For those still working with 0.3, its time to upgrade ! :) Lots of folks have already done it and it's not so hard. I think this is the most well documented and easy to use SQLAlchemy yet, and its definitely the fastest by a wide margin...many kinds of operations are 50% faster and the large majority of applications should be at least 20-30% faster. We now have hotspot profiling tests as part of our testsuite so that performance-reducing changes immediately raise red flags (and of course, performance-increasing changes unleash a shower of balloons). Congratulations! That's a huge step forward! Best wishes, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 --~--~-~--~~~---~--~~ 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] question about unicode usage.
I have a question about inconsistency in unicode handling when using a
bindparam explicitly and when using a literal when constructing my
query. It appears that if I use a unicode object in the actual query
whereclause, the convert_bind_param function of the base String will
get called(query1). However, if I use a bindparam in the whereclause
and then pass in the unicode object as the bindparam,
convert_bind_param is not called(query2).
The code below demonstrates what I am talking about. Is there a reason
that these two ways of constructing a query should have inconsistent
behavior? If I am missing something, I would appreciate any info that
would make it clear to me as to why this is the expected behavior.
Thanks,
DY
import sqlalchemy
meta = sqlalchemy.DynamicMetaData()
meta.connect ('mysql://some_dsn')
test = sqlalchemy.Table('my_test_table', meta,
sqlalchemy.Column('id', sqlalchemy.Integer, primary_key=True),
sqlalchemy.Column ('name', sqlalchemy.Unicode (255)),
mysql_engine='InnoDB',
)
query1 = sqlalchemy.select([test],
sqlalchemy.and_ (
test.c.id == sqlalchemy.bindparam ('id'),
test.c.name == u'\u201csolutions\u201d',
#option 1
)
)
results = query1.execute(id=1)
query2 = sqlalchemy.select([test],
sqlalchemy.and_ (
test.c.id == sqlalchemy.bindparam ('id'),
test.c.name == sqlalchemy.bindparam('name'),
)
)
results = query2.execute(id=1, name=u'\u201csolutions\u201d')
--~--~-~--~~~---~--~~
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: question about unicode usage.
On Oct 17, 2007, at 7:41 PM, dykang wrote:
query2 = sqlalchemy.select([test],
sqlalchemy.and_ (
test.c.id == sqlalchemy.bindparam ('id'),
test.c.name == sqlalchemy.bindparam('name'),
)
)
currently you'd have to say test.c.name == bindparam('name',
type_=String). when you say something like test.c.name == 'foo', the
__eq__() method on test.c.name looks at the other side, sees a
literal, and converts to a bindparam with a type matching its own.
with bindparam(), it doesnt make that assumption right now. but
since you bring it up, its probably a good idea for __eq__() to also
set the type on a passed in bindparam(), if the bindparam does not
already have a type assigned to it...so i added ticket 819 for that.
--~--~-~--~~~---~--~~
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: error when joining tables on multi-column primary key with bindparam
Btw this is fixed in SQLAlchemy 0.3.11. --~--~-~--~~~---~--~~ 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: error when joining tables on multi-column primary key with bindparam
On Oct 17, 2007, at 8:49 PM, dihde14 wrote: Btw this is fixed in SQLAlchemy 0.3.11. oh, sorry ! missed your original email in the crowd. yes this was ticket #768. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
