[sqlalchemy] Bug with sqlalchemy==1.2.11 causing a relation error that didn't exist with 1.2.10

Hi, I have an odd issue with sqlachemy==1.2.11 that I haven't seen before. My unit tests were failing locally after the upgrade for Lemur ( https://github.com/Netflix/lemur/ ) . When I test locally, tests pass fine with sqlachemy==1.2.10, but fail with sqlachemy==1.2.11 . Here is the travis

Re: [sqlalchemy] Bug? Query / Execute Mismatch When Given Duplicate Columns

On Tuesday, July 3, 2018 at 9:37:04 AM UTC-4, Mike Bayer wrote: > > This architecture has been liberalized but this assumption still remains > within the Core and it's possible the ORM may or may not have some > remaining reliance on this assumption as well. > I assumed the RowProxy also

Re: [sqlalchemy] Bug? Query / Execute Mismatch When Given Duplicate Columns

Yes that's intentional, the select() construct deduplicates redundant column names as for many years the result system relied upon column names in the cursor to organize its results. This architecture has been liberalized but this assumption still remains within the Core and it's possible the

[sqlalchemy] Bug? Query / Execute Mismatch When Given Duplicate Columns

Hey there! I noticed the following odd behavior: import sqlalchemy as sa engine = sa.create_engine('sqlite:///tmp.db', echo=True) tblsa = sa.Table("mytable", sa.MetaData(), autoload=True, autoload_with=engine) q = sa.select([tblsa.c.x, tblsa.c.x]) with engine.connect() as conn:

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

> > OK, this is great, it's likely not the "underscore" as much as that > the attribute is named differently from the column. I will look to > confirm this and set up a complete bug report, thanks! > Ah, that makes a lot more sense. Thanks for looking into that! Above, you are looking at

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 10:31 AM, Mike Bayer wrote: > On Tue, Jul 18, 2017 at 12:47 AM, wrote: >> Hello, I'd like to report a bug report regarding JSON nulls and >> underscore-prefixed attributes as we're upgrading from 1.0.17 to 1.1.11. >> >> I

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 12:47 AM, wrote: > Hello, I'd like to report a bug report regarding JSON nulls and > underscore-prefixed attributes as we're upgrading from 1.0.17 to 1.1.11. > > I read through the behavior at >

[sqlalchemy] Bug report with JSON nulls in 1.1.x

Hello, I'd like to report a bug report regarding JSON nulls and underscore-prefixed attributes as we're upgrading from 1.0.17 to 1.1.11. I read through the behavior at http://docs.sqlalchemy.org/en/latest/changelog/migration_11.html#change-3514 and

Re: [sqlalchemy] BUG in union with limit in PostgreSQL

Hello! Sorry, I was using old sqlalchemy, after upgrade it works fine. best regards Jarek Dnia 2017-05-12, pią o godzinie 08:54 -0400, mike bayer pisze: > > On 05/12/2017 04:55 AM, Jarek wrote: > > Hello! > > > > It looks that SQLAlchemy doesn't properly handle union with limits in > >

Re: [sqlalchemy] BUG in union with limit in PostgreSQL

On 05/12/2017 04:55 AM, Jarek wrote: Hello! It looks that SQLAlchemy doesn't properly handle union with limits in the following scenario: res1 = Session.query( Messages ).order_by( Messages.ts ).limit(100) res2 = Session.query( Messages1 ).order_by( Messages1.ts ).limit(100) res3 =

[sqlalchemy] BUG in union with limit in PostgreSQL

Hello! It looks that SQLAlchemy doesn't properly handle union with limits in the following scenario: res1 = Session.query( Messages ).order_by( Messages.ts ).limit(100) res2 = Session.query( Messages1 ).order_by( Messages1.ts ).limit(100) res3 = res1.union_all( res2 ) SQLAlchemy creates

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

there's a long term issue to get around to handling all of PG's syntaxes fully at https://bitbucket.org/zzzeek/sqlalchemy/issues/3566/figure-out-how-to-support-all-of-pgs. Current target is 1.3 because it will be a huge effort, and it may continue moving out milestones. On 05/04/2017

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

I'm working on another json query and thought I'd circle back around to see whether I'd have to continue using the original "as_row" recipe. Not sure whether Lukas was correct about sharing a similar issue as the one I originally raised. On Thursday, March 16, 2017 at 10:24:51 AM UTC-4,

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

I put up https://bitbucket.org/zzzeek/sqlalchemy/issues/3939/alias-as-column-expr-needs-tweak-to with the specific Alias issue but if you can add context what the end goal is that would be helpful, thanks. On 03/16/2017 09:56 AM, Lukas Siemon wrote: Makes perfect sense. I'll post a

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

Makes perfect sense. I'll post a complete bug report in the tracker later today (it's early morning here atm). -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

see here's what I don't get, hence why complete test case v helpful: if i fix self_group() (which yes is a bug, I can fix that), this case still fails, because the alias() has no "type": from sqlalchemy import * t = table('t', column('x')) expr = func.array_agg(select([t]).alias()) stmt =

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

func.XYZ()? I can look into that. ideally you'd be doing func.XYZ(selectable.as_scalar()), but letting alias work there is fine. On 03/15/2017 08:31 PM, Lukas Siemon wrote: Monkey patching seems to do the trick: # Patch alias self_group kwargs def patched_alias_self_group(self,

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

no idea, may I have a complete test case please? On 03/15/2017 07:53 PM, Lukas Siemon wrote: Was the underlying issue ever resolved? Running into the same error here, but my query generation is automatic, so taking it apart will take a little longer... On Thursday, 17 November 2016 07:57:56

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

Monkey patching seems to do the trick: # Patch alias self_group kwargs def patched_alias_self_group(self, target=None, **kwargs): return original_alias_self_group(self, target=target) original_alias_self_group = Alias.self_group Alias.self_group = patched_alias_self_group On Wednesday, 15

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

Was the underlying issue ever resolved? Running into the same error here, but my query generation is automatic, so taking it apart will take a little longer... On Thursday, 17 November 2016 07:57:56 UTC-8, Mike Bayer wrote: > > Hi Darin - > > That's definitely a bug because all self_group()

[sqlalchemy] Re: struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

The as_row recipe worked. Thanks for the quick response, Mike. On Thursday, November 17, 2016 at 7:25:07 AM UTC-5, Darin Gordon wrote: > > Using: postgres 9.6 and latest sqlalchemy 1.1.4 > > I've been trying to port a query to a sqlalchemy query but have gotten an > exception about an

Re: [sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

Hi Darin - That's definitely a bug because all self_group() methods are supposed to at least have a **kw to let that argument pass in. I located the one method that has this issue which is the self_group() method of Alias. However, this also suggests that an Alias object is being used in a

[sqlalchemy] struggling with postgres json related query using sqlalchemy -- sqlalchemy bug or issue with query?

Using: postgres 9.6 and latest sqlalchemy 1.1.4 I've been trying to port a query to a sqlalchemy query but have gotten an exception about an unrecognized keyword arg, which confuses me as to whether the issue is my code or a bug in sqlalchemy: TypeError: self_group() got an unexpected

Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

On 08/24/2016 03:09 PM, Gordan Todorovac wrote: Mike, python -i ~/python/sq3.py from sqlalchemy import create_engine from sqlalchemy.orm import Session e = create_engine("sqlite:///:memory:") Base.metadata.drop_all(e) Base.metadata.create_all(e) session=Session(e) rory=User("rory")

Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

Mike, Thanks for the response! Here is the demonstration, please let me know if there is something obvious that I am missing: > cat ~/python/sq3.py from sqlalchemy import Column, Integer, String, ForeignKey from sqlalchemy.orm import relationship, backref from sqlalchemy.ext.associationproxy

Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

On 08/24/2016 08:59 AM, Gordan Todorovac wrote: Hi, all - I am experiencing the issue described here http://stackoverflow.com/questions/14470688/sqlalchemy-bidirectional-relationship-association-proxy and reported as fixed here https://bitbucket.org/zzzeek/sqlalchemy/issues/2655 in the

[sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

Hi, all - I am experiencing the issue described here http://stackoverflow.com/questions/14470688/sqlalchemy-bidirectional-relationship-association-proxy and reported as fixed here https://bitbucket.org/zzzeek/sqlalchemy/issues/2655 in the latest release version of SQLAlchemy (1.0.14).

Re: [sqlalchemy] bug in QueuePool with pool_size = 1?

On 06/29/2016 05:23 PM, Jonathon Nelson wrote: I noticed some strange behavior with QueuePool when the pool_size is exactly 1. (this is with 1.0.13). With an app that basically does this: e = sa.create_engine(..., pool_size=N) while True: with e.begin() as trans: # perform a

[sqlalchemy] bug in QueuePool with pool_size = 1?

I noticed some strange behavior with QueuePool when the pool_size is exactly 1. (this is with 1.0.13). With an app that basically does this: e = sa.create_engine(..., pool_size=N) while True: with e.begin() as trans: # perform a simple query I see this behavior (observed with strace,

Re: [sqlalchemy] Bug with join?

> > > Article has a foreign key to Video and Video has a foreign key to Tag so > these can be joined either way. > This is a bit information I missed to be honest. I forgot that while Article has direct join to Video, Video can be joined to Article via Tag. I checked my relations so many

Re: [sqlalchemy] Bug with join?

On 06/13/2016 01:15 PM, Drachenfels wrote: Hi guys, I found very strange behaviour of my script, after a lot of debugging it appears that SQLAlchemy complains about joins that I cannot see exactly why it has any issue with. Full running example is below in both as inline main.py script and

[sqlalchemy] Bug with join?

Hi guys, I found very strange behaviour of my script, after a lot of debugging it appears that SQLAlchemy complains about joins that I cannot see exactly why it has any issue with. Full running example is below in both as inline main.py script and link. In the nutshell, hierarchy of objects

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On Wednesday, April 27, 2016 at 6:41:24 PM UTC+2, Mike Bayer wrote: > > > > On 04/27/2016 11:11 AM, Mike Bayer wrote: > > > > I'm improving our test suite by ensuring that result processors are > > fired off for all result proxy subtypes when caching is used as well and > > I will ensure the

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On 04/27/2016 11:11 AM, Mike Bayer wrote: I'm improving our test suite by ensuring that result processors are fired off for all result proxy subtypes when caching is used as well and I will ensure the line of code you mention is exercised. If I can reproduce your described issue at that

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On 04/26/2016 12:11 PM, Piotr Dobrogost wrote: On Tue, Apr 26, 2016 at 12:18 AM, Mike Bayer wrote: On 04/25/2016 11:04 AM, Piotr Dobrogost wrote: Is caching using dogpile what you call "Query cache extension"? If so we don't use it. this extension:

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On Tue, Apr 26, 2016 at 12:18 AM, Mike Bayer wrote: > > On 04/25/2016 11:04 AM, Piotr Dobrogost wrote: >> >> Is caching using dogpile what you call "Query cache extension"? If so >> we don't use it. > > this extension: >

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On 04/25/2016 11:04 AM, Piotr Dobrogost wrote: On Mon, Apr 25, 2016 at 3:23 PM, Mike Bayer wrote: OK I can try to work with that but that's a very specific feature, you'd need to be using the Query cache extension, I have problem finding information on "Query

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On Mon, Apr 25, 2016 at 3:23 PM, Mike Bayer wrote: > > OK I can try to work with that but that's a very specific feature, you'd > need to be using the Query cache extension, I have problem finding information on "Query cache extension". Googling for I get

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On 04/25/2016 05:49 AM, Piotr Dobrogost wrote: On Friday, April 22, 2016 at 5:22:38 PM UTC+2, Mike Bayer wrote: On 04/22/2016 10:40 AM, Piotr Dobrogost wrote: > It seems BufferedColumnResultProxy class (used only in Oracle dialect) > has a bug. I cannot confirm it,

Re: [sqlalchemy] Bug in BufferedColumnResultProxy class?

On Friday, April 22, 2016 at 5:22:38 PM UTC+2, Mike Bayer wrote: > > > On 04/22/2016 10:40 AM, Piotr Dobrogost wrote: > > It seems BufferedColumnResultProxy class (used only in Oracle dialect) > > has a bug. > > I cannot confirm it, would need a test case. Here's one that is > extremely

[sqlalchemy] Bug in BufferedColumnResultProxy class?

It seems BufferedColumnResultProxy class (used only in Oracle dialect) has a bug. _init_metadata() method defined at https://github.com/zzzeek/sqlalchemy/blob/rel_1_0_12/lib/sqlalchemy/engine/result.py#L1238 is being called even for already cached data (that's probably bug) and because this

Re: [sqlalchemy] bug with func.lower in bindparam?

On 03/25/2016 09:48 AM, Brian Cherinka wrote: Hi, Is there perhaps a bug in the sqlalchemy function lower (func.lower)? I'm trying to do a simple query that filters on a string keyword (the label of a header_keyword). I want to bind the parameter so I can easily update the label after the

[sqlalchemy] [Bug?][v0.9.8][postgres] Table.create(): checkfirst=True does NOT work for temporary tables

Hello. The following code crashes: # db init... meta = MetaData() foo = Table('tmp_foo' meta, Column('id', Integer, primary_key=True), prefixes=['TEMPORARY'], ) conn = session.connection() foo.create(conn, checkfirst=True) foo.create(conn, checkfirst=True) This is because the

Re: [sqlalchemy] [Bug?][v0.9.8][postgres] Table.create(): checkfirst=True does NOT work for temporary tables

On Dec 4, 2014, at 9:36 AM, Ladislav Lenart lenart...@volny.cz wrote: Hello. The following code crashes: # db init... meta = MetaData() foo = Table('tmp_foo' meta, Column('id', Integer, primary_key=True), prefixes=['TEMPORARY'], ) conn = session.connection()

Re: [sqlalchemy] [Bug?][v0.9.8][postgres] Table.create(): checkfirst=True does NOT work for temporary tables

Wow! Thank you! I guess this is a near-light-speed support in practice! :-) I stumbled upon this issue while I was trying to figure out how to work with temporary tables in SQLAlchemy. Final version of my code does not use the checkfirst flag at all, because I know when to create and when to

[sqlalchemy] Bug bindparam/MySql

I get an exception, when I try to use a bindparam variable twice in a query in MySql like this: TestTable.name == bindparam('username', type_ = String), TestTable.username == bindparam('username', type_ = String) - ubuntu 13.10 64bit - python 3.3.2 - sqlalchemy 0.9.3 - mysql 5.5.35 -

Re: [sqlalchemy] Bug bindparam/MySql

I'll look into what happens there but you probably need to use the same bindparam() object for now: b = bindparam('username', type_=String) tt.name == b tt.username == b On Mar 7, 2014, at 5:47 AM, Jas Per muz...@gmail.com wrote: I get an exception, when I try to use a bindparam variable

Re: [sqlalchemy] Bug bindparam/MySql

unfortunately that doesn't help - its MySql server rejecting the statement (SQlite and Postgres accept their delivered statements) thanks for helping! On Friday, March 7, 2014 3:44:00 PM UTC+1, Michael Bayer wrote: I’ll look into what happens there but you probably need to use the same

Re: [sqlalchemy] Bug bindparam/MySql

doesn't fail for me. MySQL/connector/python is up to 1.1.6 so try that. otherwise, need full log output + stack trace + exception message. 2014-03-07 11:52:06,805 INFO sqlalchemy.engine.base.Engine INSERT INTO `TestTable` (name, username) VALUES (%(name_0)s, %(username_0)s) 2014-03-07

Re: [sqlalchemy] Bug bindparam/MySql

upgrading connector to 1.1.6 didn't change anything. tried python 2.7 after that et voila: works! after some debugging found this in mysql/connector/cursor.py line 498ff: if isinstance(params, dict): for key, value in self._process_params_dict(params).items():

Re: [sqlalchemy] Bug in query with multiple joins when using joined inheritance?

I didn't think it would be, but it is a bug, yes, am applying the patch in http://www.sqlalchemy.org/trac/ticket/2759 right now. On Jun 14, 2013, at 11:52 PM, Seth P spadow...@gmail.com wrote: I've encountered what I believe to be a bug in SQLAlchemy (versions 0.8.0 and 0.8.1) in a query

Re: [sqlalchemy] Bug in query with multiple joins when using joined inheritance?

fixed in master and rel_0_8. On Jun 15, 2013, at 3:02 PM, Michael Bayer mike...@zzzcomputing.com wrote: I didn't think it would be, but it is a bug, yes, am applying the patch in http://www.sqlalchemy.org/trac/ticket/2759 right now. On Jun 14, 2013, at 11:52 PM, Seth P

[sqlalchemy] Bug in query with multiple joins when using joined inheritance?

I've encountered what I believe to be a bug in SQLAlchemy (versions 0.8.0 and 0.8.1) in a query that joins class/tables that use joined inheritance. In the code below, I would expect the three queries to produce the same output, namely [u'CCC'], but the first one gives a different (incorrect)

Re: [sqlalchemy] [BUG][PATCH] Function names not quoted when necessary

logged this as http://www.sqlalchemy.org/trac/attachment/ticket/2749 On Jun 6, 2013, at 10:27 PM, Ryan Kelly rpkell...@gmail.com wrote: Function names in SQL can contain pretty much anything, e.g.: =# create function A Bug?(integer) returns integer as $$ select $1; $$ language sql;

[sqlalchemy] [BUG][PATCH] Function names not quoted when necessary

Function names in SQL can contain pretty much anything, e.g.: =# create function A Bug?(integer) returns integer as $$ select $1; $$ language sql; CREATE FUNCTION But when attempting to use the function from SQLAlchemy: from sqlalchemy.sql.expression import func bug = getattr(func, A Bug?)(1)

[sqlalchemy] bug in dogpile advanced example?

two through twelve actually shows 25 .. 40 -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send

[sqlalchemy] [BUG] [PATCH] Calling yield_per followed by execution_options results in AttributeError

Calling yield_per on a query followed by execution_options results in the following error: Traceback (most recent call last): File /tmp/execution_options.py, line 18, in module query = query.execution_options(stream_results=True) File string, line 1, in lambda File

Re: [sqlalchemy] [BUG] [PATCH] Calling yield_per followed by execution_options results in AttributeError

that's an ImmutableDict so we can just call union() on it as we're supposed to bethis is http://www.sqlalchemy.org/trac/ticket/2661 and it's committed in reec3f59080ac, thanks ! On Feb 7, 2013, at 11:09 PM, Ryan Kelly wrote: Calling yield_per on a query followed by execution_options

Re: [sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

On Dec 5, 2012, at 6:50 PM, Derek Harland wrote: I wonder if a solution here is to somehow allow the schema argument to also be given as a tuple. eg schema=x.y would generate a DDL path as x.y schema=[x.y] would generate a DDL path as [x.y] schema=[a.b, x.y]

Re: [sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

On Dec 4, 2012, at 6:27 PM, Derek Harland wrote: Yes In that case, how does SQL server make the distinction? If things have an embedded . then SQL server would ideally make the distinction based on you quoting the database/schema names. This could be done in the Transact-SQL

Re: [sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

On 6/12/2012, at 5:26 AM, Michael Bayer wrote: On Dec 4, 2012, at 6:27 PM, Derek Harland wrote: Yes In that case, how does SQL server make the distinction? If things have an embedded . then SQL server would ideally make the distinction based on you quoting the database/schema

Re: [sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

On Dec 3, 2012, at 10:20 PM, Derek Harland wrote: The MSSQL dialect in 0.8.x seems to have had many of the reflection methods changed from something like: @reflection.cache def get_view_names(self, connection, schema=None, **kw): to @reflection.cache

Re: [sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

On 5/12/2012, at 4:30 AM, Michael Bayer wrote: On Dec 3, 2012, at 10:20 PM, Derek Harland wrote: The MSSQL dialect in 0.8.x seems to have had many of the reflection methods changed from something like: @reflection.cache def get_view_names(self, connection, schema=None, **kw):

[sqlalchemy] Bug Report: A regression in the MSSQL Dialect in 0.8.x

The MSSQL dialect in 0.8.x seems to have had many of the reflection methods changed from something like: @reflection.cache def get_view_names(self, connection, schema=None, **kw): to @reflection.cache @_db_plus_owner_listing def get_view_names(self, connection, dbname,

[sqlalchemy] Bug: Inefficient query being generated by relationship, mixin class combo

The attached script generates an inefficient query at the end: SELECT `People`.friday_id AS `People_friday_id`, `People`.parent_id AS `People_parent_id`, `People`.user_hash AS `People_user_hash` FROM `People` WHERE `People`.friday_id = %s AND `People`.user_hash = `People`.user_hash Please

Re: [sqlalchemy] Bug: Inefficient query being generated by relationship, mixin class combo

When you say this: @declared_attr def parent(cls): ... remote_side=[cls.friday_id, cls.user_hash], Delcarative calls parent within the same configuration phase that it calls user_hash for the first time to generate a new Column.So when you call upon cls.user_hash,

[sqlalchemy] Bug in joinedload('*') ?!

Hi all, I want to use session.query(...).options(joinedload('*')) to load all related objects eagerly. It seems not to work if inheritance is involved. This is a complete working example using SQLAlchemy 0.7.7 and Elixir 0.8.0dev: - from elixir import * from sqlalchemy import

Re: [sqlalchemy] Bug in joinedload('*') ?!

When you eager load from a class to itself, this is a self-referential eager load.A generic lazy=joined needs to know the depth at which you'd like to go when this occurs, otherwise it will stop as soon as it sees itself in the path of classes to be joined.The behavior of

[sqlalchemy] Bug? Cannot call super().__init__ in class which extends declarative_base

When augmenting the basehttp://docs.sqlalchemy.org/en/latest/orm/extensions/declarative.html?highlight=declarative_base#augmenting-the-baseyou create a class, and then tell declarative_base to inherit from the class you've created. Ex: class MyBase(object): def __init__(self): #

Re: [sqlalchemy] Bug? Cannot call super().__init__ in class which extends declarative_base

On Mar 8, 2012, at 1:15 PM, Adam Parkin wrote: When augmenting the base you create a class, and then tell declarative_base to inherit from the class you've created. Ex: class MyBase(object): def __init__(self): # code here Base = declarative_base(cls=MyBase) class

Re: [sqlalchemy] bug in DDL event with %

you have to escape those out with %%. On Jan 18, 2012, at 3:06 AM, lestat wrote: Hi! If I create DDL like this with %: event.listen(db.metadata, 'after_create', DDL( CREATE OR REPLACE FUNCTION test_func() RETURNS void AS $$ DECLARE max_user_id INTEGER; BEGIN

Re: [sqlalchemy] bug in reflection.py sqla 0.7.3

I'm not able to reproduce that, and also this code should likely be replaced by our existing topological sort code. Can you provide a succinct reproducing example ? On Dec 1, 2011, at 2:22 AM, Robert Forkel wrote: Hi, trying to use Inspector.get_table_names with order_by='foreign_key'

Re: [sqlalchemy] bug in reflection.py sqla 0.7.3

nevermind, I need to randomize that list in order to trigger it On Dec 1, 2011, at 1:42 PM, Michael Bayer wrote: I'm not able to reproduce that, and also this code should likely be replaced by our existing topological sort code. Can you provide a succinct reproducing example ? On Dec

Re: [sqlalchemy] bug in reflection.py sqla 0.7.3

thats fixed in r2b66b5abf755, will be in 0.7.4 or you can get the tip off the download page. On Dec 1, 2011, at 1:47 PM, Michael Bayer wrote: nevermind, I need to randomize that list in order to trigger it On Dec 1, 2011, at 1:42 PM, Michael Bayer wrote: I'm not able to reproduce

[sqlalchemy] bug in reflection.py sqla 0.7.3

Hi, trying to use Inspector.get_table_names with order_by='foreign_key' causes the following exception: Traceback (most recent call last): File db_inspector.py, line 20, in module for table in insp.get_table_names(schema=schema, order_by='foreign_key'): File

[sqlalchemy] Bug? Declarative syntax for double self-referential constructs with association object

Hello List I'd like to define a many-to-many relationship using the declarative syntax between a table to itself, but employing an association object (since I require the association to have attributes also). Here's what I tried:

Re: [sqlalchemy] Bug? Declarative syntax for double self-referential constructs with association object

On Aug 26, 2011, at 9:36 PM, Michael Bayer wrote: the error message here isn't fantastic but I think you mean to say: oa = ObjectAssociation() o2.relate_down.append(oa) o.relate_up.append(oa) as relate_up/relate_down accept ObjectAssociation objects, not Object objects, as members.

Re: [sqlalchemy] Bug? Declarative syntax for double self-referential constructs with association object

On Aug 26, 2011, at 4:06 PM, Thomas Jacob wrote: On Aug 26, 2011, at 9:36 PM, Michael Bayer wrote: the error message here isn't fantastic but I think you mean to say: oa = ObjectAssociation() o2.relate_down.append(oa) o.relate_up.append(oa) as relate_up/relate_down accept

[sqlalchemy] bug: distinct ON using subquery with un-named alias fails.

I have a test case. If this formats badly, I'll attach it as a file. I'm not sure if this is a distinct on problem or not (probably not, but here is a test case anyway). If I don't specify a name for the alias, the compile fails. :-( diff -r 070e47edcfad test/dialect/test_postgresql.py ---

Re: [sqlalchemy] bug: distinct ON using subquery with un-named alias fails.

yeah lets start using trac for these, these are bugs with tests. this is http://www.sqlalchemy.org/trac/ticket/2142 and your previous one is 2141 On Apr 21, 2011, at 1:31 PM, Jon Nelson wrote: diff -r 070e47edcfad test/dialect/test_postgresql.py --- a/test/dialect/test_postgresql.py Fri

Re: [sqlalchemy] Bug in mssql dialect?

You are right. Thanks once again. On Mar 3, 2011, at 11:11, Michael Bayer mike...@zzzcomputing.com wrote: That looks certainly like a misconfigured relationship(). Not sure why SQLite would let it pass through (sqlite is in general extremely liberal), but that's clearly a literal string

[sqlalchemy] Bug in mssql dialect?

Last line is invalid t-sql. The ‘==’ should just be ‘=’. I get the problem when using mssql but not with sqlite. Saw the bug on sqa version 0.6.6, upgraded to 0.7b2 and still having issue. Please let me know if you need more info and I'll be happy to provide. Thanks, Michael Traceback (most

Re: [sqlalchemy] Bug in mssql dialect?

That looks certainly like a misconfigured relationship(). Not sure why SQLite would let it pass through (sqlite is in general extremely liberal), but that's clearly a literal string passed to a join expression sent to relationship as in relationship(... primaryjoin=and_(some expression,

Re: [sqlalchemy] bug with declarative's _decl_class_registry

On 05/10/2010 18:03, Michael Bayer wrote: Also, is there a 'trunk' or 'tip' anywhere now to put 0.7-targeted code? there's not. You'd make a bitbucket repo and link to it on the trac ticket. Done: http://www.sqlalchemy.org/trac/changeset/6868:d8580d6765d4

[sqlalchemy] bug with declarative's _decl_class_registry

Hi All, Start off with a base.py module: from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() Now, say we have a module, a.py: from sqlalchemy import * from base import Base class Something(Base): __tablename__ = 'foo' id = Column('id', Integer,

Re: [sqlalchemy] bug with declarative's _decl_class_registry

On Oct 5, 2010, at 11:04 AM, Chris Withers wrote: Hi All, Start off with a base.py module: from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() Now, say we have a module, a.py: from sqlalchemy import * from base import Base class Something(Base):

Re: [sqlalchemy] bug with declarative's _decl_class_registry

On 05/10/2010 16:10, Michael Bayer wrote: I think an exception should be raised if a class name already exists in _decl_class_registry when the assignment is made in _as_declarative. yeah definitely, though in 0.6 it needs to be a warning to start since some folks might be doing this

Re: [sqlalchemy] bug with declarative's _decl_class_registry

On Oct 5, 2010, at 12:37 PM, Chris Withers wrote: On 05/10/2010 16:10, Michael Bayer wrote: I think an exception should be raised if a class name already exists in _decl_class_registry when the assignment is made in _as_declarative. yeah definitely, though in 0.6 it needs to be a warning

Re: [sqlalchemy] bug in sqllite dialect?

Chris Withers wrote: Michael Bayer wrote: Chris Withers wrote: Michael Bayer wrote: Has anyone (hi, list, talking to you too!) already done a custom type for this specific problem? people do custom types for all sorts of things. In the case of the Decimal here I'd likely subclass

Re: [sqlalchemy] bug in sqllite dialect?

Michael Bayer wrote: the whole ugly discussion is at http://www.sqlalchemy.org/trac/ticket/1759 Speshul... *sigh* I'm glad I don't have your responsibilities ;-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- You

Re: [sqlalchemy] bug in sqllite dialect?

Michael Bayer wrote: Has anyone (hi, list, talking to you too!) already done a custom type for this specific problem? people do custom types for all sorts of things. In the case of the Decimal here I'd likely subclass sqlalchemy.databases.sqlite.SLNumeric which should ensure that your own

Re: [sqlalchemy] bug in sqllite dialect?

Chris Withers wrote: Michael Bayer wrote: Has anyone (hi, list, talking to you too!) already done a custom type for this specific problem? people do custom types for all sorts of things. In the case of the Decimal here I'd likely subclass sqlalchemy.databases.sqlite.SLNumeric which should

Re: [sqlalchemy] bug in sqllite dialect?

Hi Michael, Thanks for this, I thought I asked this separately but I can't find the mail now... How would you recommend I work this now in 0.5.8 until I can move to 0.6.0? (which will take some months :-S) I seem to remember you suggesting a custom type. Where can I find examples of those

Re: [sqlalchemy] bug in sqllite dialect?

Chris Withers wrote: Hi Michael, Thanks for this, I thought I asked this separately but I can't find the mail now... How would you recommend I work this now in 0.5.8 until I can move to 0.6.0? (which will take some months :-S) I seem to remember you suggesting a custom type. Where can I

[sqlalchemy] bug in DROP TABLE CASCADE

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When reading the code in the `sql.compiler` module, I noted this: def visit_drop_table(self, drop): ret = \nDROP TABLE + self.preparer.format_table(drop.element) if drop.cascade: ret += CASCADE CONSTRAINTS

Re: [sqlalchemy] bug in DROP TABLE CASCADE

On Feb 28, 2010, at 8:09 PM, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Bayer ha scritto: On Feb 28, 2010, at 3:21 PM, Manlio Perillo wrote: When reading the code in the `sql.compiler` module, I noted this: def visit_drop_table(self, drop):

Re: [sqlalchemy] bug in sqllite dialect?

Michael Bayer wrote: not sure if this is obvious, its the sqlite3.PARSE_DECLTYPES. The SQLite date types don't expect this to be turned on. That is a handy feature which I'm not sure was available in such a simple form when I first wrote against the pysqlite dialect in Python 2.3. Indeed,

Re: [sqlalchemy] bug in sqllite dialect?

On Feb 26, 2010, at 8:50 AM, Chris Withers wrote: Michael Bayer wrote: not sure if this is obvious, its the sqlite3.PARSE_DECLTYPES. The SQLite date types don't expect this to be turned on. That is a handy feature which I'm not sure was available in such a simple form when I first wrote

Re: [sqlalchemy] bug in sqllite dialect?

On Feb 26, 2010, at 8:50 AM, Chris Withers wrote: Michael Bayer wrote: not sure if this is obvious, its the sqlite3.PARSE_DECLTYPES. The SQLite date types don't expect this to be turned on. That is a handy feature which I'm not sure was available in such a simple form when I first wrote

Re: [sqlalchemy] bug in sqllite dialect?

ticket #1717 On Feb 26, 2010, at 10:28 AM, Michael Bayer wrote: On Feb 26, 2010, at 8:50 AM, Chris Withers wrote: Michael Bayer wrote: not sure if this is obvious, its the sqlite3.PARSE_DECLTYPES. The SQLite date types don't expect this to be turned on. That is a handy feature which

  1   2   >