[sqlalchemy] High resolution SQLAlchemy logo
Hi, I think to print SQLAlchemy logo on our company brochure. I think it is permissible. Is not so? Is there a high resolution logo somewhere? thanks Sanjay --~--~-~--~~~---~--~~ 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] Query objects and empty slices
Greetings Alchemists, I really like the transparent slicing of Query object but there seems to be a bug some with empty slices. First or all, fire up your favorite Python shell and convince yourself that all or those return empty lists: range(10)[:0] range(10)[0:0] range(10)[1:1] Now, if you were to apply the same slices to a query object, you would be shocked as you notice that only the last returns an empty list; the fist two return the whole database. I looked in orm.Query.__getitem__ and the handling of slices seems to be correct. As and example, both q[:0]._limit and q[1:1]._limit return 0. My guess is that the underlying Select object does not take limit into account when offset is 0. You will all agree that this is a bug and that it needs to be fixed. I don't mind digging into the sources to fix it. Can anyone point me in the right direction? -- Yannick Gingras --~--~-~--~~~---~--~~ 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: Query objects and empty slices
On May 2, 2008, at 6:33 AM, Yannick Gingras wrote: My guess is that the underlying Select object does not take limit into account when offset is 0. you mean, a limit of zero itself is ignored. an offset of zero doesn't affect limit. You will all agree that this is a bug and that it needs to be fixed. I don't mind digging into the sources to fix it. Can anyone point me in the right direction? if the limit is zero Id imagine that no SQL would be issued at all. do you agree ? --~--~-~--~~~---~--~~ 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: Query objects and empty slices
Michael Bayer [EMAIL PROTECTED] writes: My guess is that the underlying Select object does not take limit into account when offset is 0. you mean, a limit of zero itself is ignored. an offset of zero doesn't affect limit. When _offset is 0 or None, _limit seems to be ignored. There might be something else but I see: print q[:0] # no limit statement in the SQL print q[0:0] # no limit statement in the SQL print q[1:1] # limit statement is there You will all agree that this is a bug and that it needs to be fixed. I don't mind digging into the sources to fix it. Can anyone point me in the right direction? if the limit is zero Id imagine that no SQL would be issued at all. do you agree ? That's one way to see it and it would make sense. However, issuing the query anyway validates that aside from returning nothing, all the selected tables are there. My preference goes for returning an empty list without emitting SQL. -- Yannick Gingras --~--~-~--~~~---~--~~ 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: Query objects and empty slices
On May 2, 2008, at 10:52 AM, Yannick Gingras wrote: When _offset is 0 or None, _limit seems to be ignored. There might be something else but I see: print q[:0] # no limit statement in the SQL print q[0:0] # no limit statement in the SQL print q[1:1] # limit statement is there the first two have a LIMIT of zero. Did you try: print q[0:10] ? --~--~-~--~~~---~--~~ 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: mssql, Linux, unixODBC - Could not locate column in row for column
On Tue, Apr 22, 2008 at 9:35 AM, Lukasz Szybalski [EMAIL PROTECTED] wrote:
e = sqlalchemy.create_engine(mssql://xxx:[EMAIL
PROTECTED]:1433/xx?driver=TDSodbc_options='TDS_Version=8.0')
here is a patch to mssql.py that makes above line work.
805c805,808
connectors.append(keys.pop('odbc_options'))
---
odbc_options=keys.pop('odbc_options')
if odbc_options[0]==' and odbc_options[-1]==':
odbc_options=odbc_options[1:-1]
connectors.append(odbc_options)
Could you guys add it in to svn.
Any news on this? Should I create a ticket so we don't forget about this?
Lucas
--~--~-~--~~~---~--~~
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: sequence-related question
Michael, yes, i think the seq is automatically executed in that case.
Regarding the usage of currval i dunno. Sorry
2008/4/30, Michael Bayer [EMAIL PROTECTED]:
On Apr 30, 2008, at 3:45 PM, Eric Lemoine wrote:
With psycopg2, I know people using this:
sql = INSERT INTO \%s\ (%s) VALUES (%s) % (self.table, columns,
values)
cursor = db.cursor()
cursor.execute(str(sql), values)
cursor.execute(SELECT currval('%s'); % sequence_name)
id = cursor.fetchone()[0]
self.db.commit()
I'm wondering if this is safe. And if so, if there's a way to do the
same with SA.
this is a slight bit less safe than SQLA's default practice, in the
sense that if the application used the same connection in two
concurrent threads (which is a bad practice in itself), the results
may be incorrect.
What I dont see above is how the sequence is getting executed. Is the
column a SERIAL column, and the sequence is executed automatically ?
or is the nextval(seqname) embedded into the VALUES clause above
literally ?
also still curious why usage of currval is even needed.
--~--~-~--~~~---~--~~
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: mssql, Linux, unixODBC - Could not locate column in row for column
There's a Dialect refactor underway for 0.5.0 that will likely change the way that options are fed to db engines: http://groups.google.com/group/sqlalchemy/browse_thread/thread/36fd2e935b165d70 Part of that work will probably have some influence on the dburi and create_engine(**kwargs) option specification, as both ODBC and JDBC have a lot of options that can be specified. So the odbc_options= keyword is likely to be short-lived anyway. For now, I've applied your patch verbatim, since you're the only one using it. r4621 -rick --~--~-~--~~~---~--~~ 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: join inheritance and mutual foreign keys behind tables
Awesome. For now, the inherit_condition mapper arg is working fine, so thanks for that. On Thu, May 1, 2008 at 9:03 PM, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2008, at 6:25 PM, Bobby Impollonia wrote: It no longer works. In particular, I get class 'sqlalchemy.exceptions.InvalidRequestError': Could not find table 'child2' with which to generate a foreign key I actually have a fix for this in r4614, which is essentially similar to the workaround I gave you. --~--~-~--~~~---~--~~ 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: mssql, Linux, unixODBC - Could not locate column in row for column
Rick Morrison wrote: There's a Dialect refactor underway for 0.5.0 that will likely change the way that options are fed to db engines: Currently the munging of url params and connect_args into a connect() lambda is happening outside of the dialect's control. In 0.5 that's all moving into dialect-land and the dialects will be able to receive connect_args (e.g. processing odbc_options, if specified there). There'll be opportunities for dialects to set up pool events as well. --~--~-~--~~~---~--~~ 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] possible bug with join inheritance and contains()
I have a class that I will call Child which inherits via join inheritance from a class I will call Parent. There is a many-to-many relationship between Child and a class that I will call Other. A query that looks like this: child = some child Other.query.filter(not_(other.child_objects.contains(child))).first() Generates sql that looks like: SELECT other columns FROM other WHERE NOT (EXISTS (SELECT 1 FROM other_child, child, parent WHERE other.id = other_child.other_id AND child.id = other_child.child_id AND parent.id = %s)) ORDER BY other.id LIMIT 0, 1 The subquery (unnecessarily) includes the parent table. However, it does not join the parent table with the child table, so the subquery will always be true as long as there is any entry for the other in other_child, even if it is not with the child we care about. --~--~-~--~~~---~--~~ 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: mssql, Linux, unixODBC - Could not locate column in row for column
Sounds nice, thanks for the heads-up. There'll be opportunities for dialects to set up pool events as well. One of the things I'm looking to see is better reconnect support for dead database connections from network partitions, sql server restarts, etc. Is that going to be fully Dialect controlled, or is there some coming support for auto-reconnect as well? --~--~-~--~~~---~--~~ 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: possible bug with join inheritance and contains()
On May 2, 2008, at 2:14 PM, Bobby Impollonia wrote: A query that looks like this: child = some child Other.query.filter(not_(other.child_objects.contains(child))).first() immediate workaround: other.child_objects.of_type(Child).contains(child) bug is fixed in r4627. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
