sqlalchemy-tickets — trac tickets and updates forwarded to this list

[Sqlalchemy-tickets] Issue #2980: SyntaxErrors in test suite with Python 3.2 (zzzeek/sqlalchemy)

[Arfrever F. T. A. <iss...@bi...>]

New issue 2980: SyntaxErrors in test suite with Python 3.2
https://bitbucket.org/zzzeek/sqlalchemy/issue/2980/syntaxerrors-in-test-suite-with-python-32

Arfrever Frehtes Taifersar Arahesis:

```
$ python3.2 -m compileall -fq test
*** Error compiling 'test/dialect/test_sqlite.py'...
  File "test/dialect/test_sqlite.py", line 114
    [(u'2004-05-21T00:00:00',), (u'2010-10-15T12:37:00',)]
                           ^
SyntaxError: invalid syntax

*** Error compiling 'test/orm/test_default_strategies.py'...
  File "test/orm/test_default_strategies.py", line 164
    eq_(q.all(), [(u'jack',), (u'ed',), (u'fred',), (u'chuck',)])
                         ^
SyntaxError: invalid syntax

*** Error compiling 'test/orm/test_subquery_relations.py'...
  File "test/orm/test_subquery_relations.py", line 1704
    (1, u'/1.jpg', 1, 1),
                ^
SyntaxError: invalid syntax

*** Error compiling 'test/sql/test_update.py'...
  File "test/sql/test_update.py", line 309
    checkparams={u'addresses_name': 'new address', 'name': 'newname'},
                                 ^
SyntaxError: invalid syntax

```

[Sqlalchemy-tickets] Issue #2979: Test failures with Python 3.4 (zzzeek/sqlalchemy)

[Arfrever F. T. A. <iss...@bi...>]

New issue 2979: Test failures with Python 3.4
https://bitbucket.org/zzzeek/sqlalchemy/issue/2979/test-failures-with-python-34

Arfrever Frehtes Taifersar Arahesis:

SQLAlchemy test suite has at least 11 errors and at least 3 failures with Python 3.4.

test.orm.test_attributes.AttributesTest.test_pickleness() fails due to hash randomization, so it might be necessary to run test suite multiple times to reproduce this failure.

I attach output of test suite of SQLAlchemy trunk with snapshot of Python 3.4 from today.

[Sqlalchemy-tickets] Issue #2978: .listen() on Engine-level events fired from Connection does not work for in-progress Sessions if it's the first listener (zzzeek/sqlalchemy)

[Alan S. <iss...@bi...>]

New issue 2978: .listen() on Engine-level events fired from Connection does not work for in-progress Sessions if it's the first listener
https://bitbucket.org/zzzeek/sqlalchemy/issue/2978/listen-on-engine-level-events-fired-from

Alan Shreve:

Here's the succinct code explanation:

    sess = Session()
    sess.query(A).all()
    sqlalchemy.event.listen(engine, "before_execute", before_execute_cb)
    sess.query(A).all() # <--- USE THE SAME SESSION AS BEFORE

That second query *does not* trigger before_execute_cb. I expect it to trigger that. However, if you do this:

    # Register dummy listener to force Connection's dispatch descriptor to join with Engine's
    sqlalchemy.event.listen(engine, "before_execute", noop_fn)
    sess = Session()
    sess.query(A).all()
    sqlalchemy.event.listen(engine, "before_execute", before_execute_cb)
    sess.query(A).all() # <--- USE THE SAME SESSION AS BEFORE

This time, the second query *does* trigger before_execute_cb.

A full set of cases: 
https://gist.github.com/inconshreveable/9300571

This is a very subtle problem in the initialization of the dispatcher on Connection objects. The bug is here:

https://bitbucket.org/zzzeek/sqlalchemy/src/fa23570a338b53c813b6342fba0cacd4f5e61384/lib/sqlalchemy/engine/base.py?at=master#cl-66

I'm not well-versed enough in SQLAlchemy design to decide how to solve this, but my suggestion is probably:

Connection objects should *always* join with the Engine's dispatch object and when registering a new event listener on the Engine's dispatch object, it needs to iterate each open connection and set _has_events to True.

[Sqlalchemy-tickets] Issue #2977: tuple_() needs to record heterogeneous types (zzzeek/sqlalchemy)

[Mike B. <iss...@bi...>]

New issue 2977: tuple_() needs to record heterogeneous types
https://bitbucket.org/zzzeek/sqlalchemy/issue/2977/tuple_-needs-to-record-heterogeneous-types

Mike Bayer:


```
#!python

from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class HashTest(Base):
    __tablename__ = 'hash_test'

    hash_val = Column(Binary, primary_key=True)
    hash_type = Column(String, primary_key=True)

e = create_engine("postgresql://scott@localhost/test", echo=True)

Base.metadata.drop_all(e)
Base.metadata.create_all(e)

s = Session(e)
s.add_all([
    HashTest(hash_val='im binary 1', hash_type='im string 1'),
    HashTest(hash_val='im binary 2', hash_type='im string 2'),
])
s.commit()

filter_cols = tuple_(HashTest.hash_val, HashTest.hash_type)
requested_cols = ('im binary 1', 'im string 1')

print s.query(HashTest).filter(filter_cols.in_([requested_cols])).all()

```

patch:


```
#!diff

diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py
index f2ce061..96c51bd 100644
--- a/lib/sqlalchemy/sql/elements.py
+++ b/lib/sqlalchemy/sql/elements.py
@@ -1859,6 +1859,8 @@ class Tuple(ClauseList, ColumnElement):
         self.type = kw.pop('type_', None)
         if self.type is None:
             self.type = _type_from_args(clauses)
+        self._type_tuple = [arg.type for arg in clauses]
+
         super(Tuple, self).__init__(*clauses, **kw)
 
     @property
@@ -1868,8 +1870,8 @@ class Tuple(ClauseList, ColumnElement):
     def _bind_param(self, operator, obj):
         return Tuple(*[
             BindParameter(None, o, _compared_to_operator=operator,
-                             _compared_to_type=self.type, unique=True)
-            for o in obj
+                             _compared_to_type=type_, unique=True)
+            for o, type_ in zip(obj, self._type_tuple)
         ]).self_group()

```

consider that we should try to whack ".type" off of Tuple entirely as the type system can't represent that right now.

[Sqlalchemy-tickets] Issue #2976: innerjoin=True is ignored on second joinedload() option (zzzeek/sqlalchemy)

[Ezra E. <iss...@bi...>]

New issue 2976: innerjoin=True is ignored on second joinedload() option
https://bitbucket.org/zzzeek/sqlalchemy/issue/2976/innerjoin-true-is-ignored-on-second

Ezra Epstein:

How should be (IMO):
   1. joinedload  (and join / contains_eager) should, by default, use the semantics of the declared / mapped relationship if there is one.  Thus if the relationship is a to-one (uselist=False or innerjoin=True), then those attributes of the relationship should be discovered and used when building the SQL query.
   2.  If one specifies innerjoin=True on the (second) joinedload() it should be honored on that join.

How it is:
    session.query(AClass).options(joinedload(AClass.rel1).joinedload(RelClass.rel2, innerjoin=True)).filter(AClass.attrib=='whatever').one()

Yields two regular (default left outer) JOIN clauses.  

It should (I think) have INNER JOIN on the second of those clauses.

[Sqlalchemy-tickets] Issue #2975: Importing * from sqlalchemy.orm.interfaces causes AttributeError (zzzeek/sqlalchemy)

[Dane L. <iss...@bi...>]

New issue 2975: Importing * from sqlalchemy.orm.interfaces causes AttributeError
https://bitbucket.org/zzzeek/sqlalchemy/issue/2975/importing-from-sqlalchemyorminterfaces

Dane Larsen:

This bug appears on both 0.9.3 and the latest development version (from Github). I also have an installation of 0.5.8, which does not exhibit the bug.

To reproduce, simply run the following in the Python interpreter:

>>> from sqlalchemy.orm.interfaces import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'ExtensionOption'

Due to the simplicity of the bug, I wasn't sure if I was just missing something obvious, but a quick search didn't lead to any relevant information on ExtensionOption. 

[Sqlalchemy-tickets] Issue #2974: Union queries fail if there are literal unlabeled columns (zzzeek/sqlalchemy)

[yajo <iss...@bi...>]

New issue 2974: Union queries fail if there are literal unlabeled columns
https://bitbucket.org/zzzeek/sqlalchemy/issue/2974/union-queries-fail-if-there-are-literal

yajo:

See this union query:

```
#!python

queries = list()

queries.append(sql.select(
    columns=[
        sql.expression.literal("column_1").label("label_1"),
        sql.expression.literal("column_2").label("label_2"),
    ],
    bind=conn.engine
))

queries.append(sql.select(
    columns=[
        sql.expression.literal("column_1"),
        sql.expression.literal("column_2"),
    ],
    bind=conn.engine
))

one = sql.expression.union(*queries)
```

It fails with this exception:

```
sqlalchemy.exc.ArgumentError: All selectables passed to CompoundSelect must have identical numbers of columns; select #1 has 2 columns, select #2 has 1
```

But both have 2 columns, it's just that the 2nd one is not labeled (because it is not needed in union queries, at least with MySQL).

**Workaround:** labeling all columns in 2nd query.

Notice that *real* columns, wich automatically seem to get a name, don't expose this weird behavior.

[Sqlalchemy-tickets] Issue #2973: Event removal not working (zzzeek/sqlalchemy)

[Konsta V. <iss...@bi...>]

New issue 2973: Event removal not working
https://bitbucket.org/zzzeek/sqlalchemy/issue/2973/event-removal-not-working

Konsta Vesterinen:

Very simple test scenario:


```
#!python


import sqlalchemy as sa


@sa.event.listens_for(sa.orm.mapper, 'instrument_class')
def my_listener(mapper, cls):
    pass


sa.event.remove(
    sa.orm.mapper, 'instrument_class', my_listener
)
```

This throws a ValueError:

```
#!python

    def remove(self, event_key):
        target = event_key.dispatch_target
        stack = [target]
        while stack:
            cls = stack.pop(0)
            stack.extend(cls.__subclasses__())
            if cls in self._clslevel:
>               self._clslevel[cls].remove(event_key.fn)
E               ValueError: list.remove(x): x not in list

```

Maybe the `event_key.fn` should be `event_key.fn_wrap` instead?

[Sqlalchemy-tickets] Issue #2972: Support for calling Stored Procedures (not functions) (zzzeek/sqlalchemy)

[Ronny P. <iss...@bi...>]

New issue 2972: Support for calling Stored Procedures (not functions)
https://bitbucket.org/zzzeek/sqlalchemy/issue/2972/support-for-calling-stored-procedures-not

Ronny Pfannschmidt:

oracle stored procedures cant be invoked by a select, instead one must call them in a anonymous block

a way to either access those via the dbapi.callproc method or generating the fit sql would be nice

currently i work around by compiling to a block on oracle and a select on postgresql
i didnt examine other databases

[Sqlalchemy-tickets] Issue #2971: move .info from MapperProperty down to _InspectionAttr (zzzeek/sqlalchemy)

[Mike B. <iss...@bi...>]

New issue 2971: move .info from MapperProperty down to _InspectionAttr
https://bitbucket.org/zzzeek/sqlalchemy/issue/2971/move-info-from-mapperproperty-down-to

Mike Bayer:

this will give us an .info collection on all ORM attributes including hybrids and assocaition proxies, and also on mapper/aliasedinsp, e.g. when you say inspect(SomeClass), which might be useful.

[Sqlalchemy-tickets] Issue #2970: Installation guide should mention that standard "pip install" won't include C extensions (zzzeek/sqlalchemy)

[craigholm <iss...@bi...>]

New issue 2970: Installation guide should mention that standard "pip install" won't include C extensions
https://bitbucket.org/zzzeek/sqlalchemy/issue/2970/installation-guide-should-mention-that

craigholm:

The current version of pip defaults to installing from wheels, when they're available.  This means, by default, "pip install sqlalchemy" will never include C extensions.  The installation guide, however, states that C extensions are included unless the platform doesn't support them, and that it shows a warning in this case.

In my opinion it won't be obvious to most users why the C extensions are omitted.  The installation guide should mention that pip's "--no-use-wheel" option needs to be specified to install C extensions.

[Sqlalchemy-tickets] Issue #2969: Join rewriting (?maybe?) issue (union and joined table inheritance involved) (zzzeek/sqlalchemy)

[dairiki <iss...@bi...>]

New issue 2969: Join rewriting (?maybe?) issue (union and joined table inheritance involved)
https://bitbucket.org/zzzeek/sqlalchemy/issue/2969/join-rewriting-maybe-issue-union-and

dairiki:

This is a regression in 0.9.4.
I suspect this is an issue only with sqlite.
A test script which exercises the problem is attached.

### Symptoms ###
With
```
class A(Base):
    __tablename__ = 'A'
    id = sa.Column(sa.Integer, primary_key=True)
    typ = sa.Column(sa.Integer, nullable=False)
    __mapper_args__ = {'polymorphic_on': typ}
    b_id = sa.Column(sa.ForeignKey('B.id'), nullable=False)

class A1(A):
    __tablename__ = 'A1'
    __mapper_args__ = {'polymorphic_identity': 1}
    id = sa.Column(sa.ForeignKey(A.id), primary_key=True)

class A2(A):
    __tablename__ = 'A2'
    __mapper_args__ = {'polymorphic_identity': 2}
    id = sa.Column(sa.ForeignKey(A.id), primary_key=True)

class B(Base):
    __tablename__ = 'B'
    id = sa.Column(sa.Integer, primary_key=True)
    a1s = sa.orm.relationship(A1)
    a2s = sa.orm.relationship(A2)
```

`sess.query(B).join(B.a1s).join(sess.query(B).join(B.a2s))` compiles erroneously to
```
SELECT anon_1."B_id" AS "anon_1_B_id" FROM (
  SELECT "B".id AS "B_id" 
    FROM "B"
     JOIN (
       SELECT "A".id AS "A_id",
              "A".typ AS "A_typ",
              "A".b_id AS "A_b_id",
              "A1".id AS "A1_id" 
         FROM "A" JOIN "A1" ON "A".id = "A1".id
     ) AS anon_2 ON "B".id = anon_2."A_b_id"
  UNION SELECT "B".id AS "B_id" 
    FROM "B"
     JOIN (
       SELECT anon_2."A_id" AS "A_id", 
              anon_2."A_typ" AS "A_typ",
              anon_2."A_b_id" AS "A_b_id",
              anon_2."A1_id" AS "A1_id",
              "A2".id AS "A2_id" 
         FROM (
           SELECT "A".id AS "A_id",
                  "A".typ AS "A_typ",
                  "A".b_id AS "A_b_id",
                  "A1".id AS "A1_id" 
             FROM "A" JOIN "A1" ON "A".id = "A1".id
         ) AS anon_2
          JOIN "A2" ON anon_2."A_id" = "A2".id
      ) AS anon_3 ON "B".id = anon_3."A_b_id"
) AS anon_1
```

Note that in the the second part of the union (the part corresponding to `sess.query(B).join(B.a2s)` is effectively joining `A` with both `A1` and `A2`
(which always results in zero rows, since an A is either an A1 or an A2, never both.)

[Sqlalchemy-tickets] Issue #2968: Syntax error in WindowedRangeQuery example code (zzzeek/sqlalchemy)

[Julian O <iss...@bi...>]

New issue 2968: Syntax error in WindowedRangeQuery example code
https://bitbucket.org/zzzeek/sqlalchemy/issue/2968/syntax-error-in-windowedrangequery-example

Julian O:

The code in:

http://www.sqlalchemy.org/trac/wiki/UsageRecipes/WindowedRangeQuery

contains the line:


```
#!python
intervals = [for id, in q](id)

```

That's not valid Python 2.7 syntax. I don't think it is valid Python 3.x either. What expression is missing?

[Sqlalchemy-tickets] Issue #2967: eager loaders generate incorrect SQL when loading a class mapped to a join (zzzeek/sqlalchemy)

[monsanto <iss...@bi...>]

New issue 2967: eager loaders generate incorrect SQL when loading a class mapped to a join
https://bitbucket.org/zzzeek/sqlalchemy/issue/2967/eager-loaders-generate-incorrect-sql-when

monsanto:

See attached test.

There are three tables "A", "AB", "B", and "C". AB joins A and B.

We desire to relate "A" and "B", but allow the Bs to know what A they came from. To do this, we make a new class BFromA, map it to join(AB, B), and declare a relationship() between A and BFromA.

If you try to joinedload() BFromAs, you get two different possible SQL queries, depending on whether you str() the query, or execute it.

str() gives the correct result:

```
SELECT a.a_id AS a_a_id, ab_1.b_id AS ab_1_b_id, b_1.b_id AS b_1_b_id, ab_1.a_id AS ab_1_a_id 
FROM a 
LEFT OUTER JOIN (ab AS ab_1 JOIN b AS b_1 ON b_1.b_id = ab_1.b_id) 
ON a.a_id = ab_1.a_id
```

Executing gives an incorrect result: notice how the joined tables have been changed to a SELECT:

```
SELECT a.a_id AS a_a_id, anon_1.ab_1_b_id AS ab_1_b_id, anon_1.b_1_b_id AS b_1_b_id, anon_1.ab_1_a_id AS ab_1_a_id 
FROM a 
LEFT OUTER JOIN (SELECT ab_1.a_id AS ab_1_a_id, ab_1.b_id AS ab_1_b_id, b_1.b_id AS b_1_b_id FROM ab AS ab_1 JOIN b AS b_1 ON b_1.b_id = ab_1.b_id) AS anon_1 
ON a.a_id = anon_1.ab_1_a_id
```

By changing the joined tables to a SELECT, we break any correlated subqueries. We define table C to be a subset of Bs, and add a column_property to BFromA that checks if the current B is in this set. The following is the output of `python 3.3 bugtest.py` watch as the lazyload and str() joinedload correlate the B correctly with the subquery, and the executed joinedload/subqueryload decorrelate the B.

```
**Lazy load:

2014-02-19 21:19:24,805 INFO sqlalchemy.engine.base.Engine BEGIN (implicit)
2014-02-19 21:19:24,806 INFO sqlalchemy.engine.base.Engine SELECT ab.b_id AS ab_b_id, b.b_id AS b_b_id, EXISTS (SELECT * 
FROM c 
WHERE c.b_id = b.b_id) AS anon_1, ab.a_id AS ab_a_id 
FROM ab JOIN b ON b.b_id = ab.b_id
 LIMIT ? OFFSET ?
2014-02-19 21:19:24,806 INFO sqlalchemy.engine.base.Engine (1, 0)

**Joined load str():

SELECT a.a_id AS a_a_id, ab_1.b_id AS ab_1_b_id, b_1.b_id AS b_1_b_id, EXISTS (SELECT * 
FROM c 
WHERE c.b_id = b_1.b_id) AS anon_1, ab_1.a_id AS ab_1_a_id 
FROM a LEFT OUTER JOIN (ab AS ab_1 JOIN b AS b_1 ON b_1.b_id = ab_1.b_id) ON a.a_id = ab_1.a_id

**Joined load:

2014-02-19 21:01:50,012 INFO sqlalchemy.engine.base.Engine BEGIN (implicit)
2014-02-19 21:01:50,013 INFO sqlalchemy.engine.base.Engine SELECT a.a_id AS a_a_id, anon_1.ab_1_b_id AS ab_1_b_id, anon_1.b_1_b_id AS b_1_b_id, EXI
STS (SELECT *                                                                                                                                     
FROM c, b AS b_1 
WHERE c.b_id = b_1.b_id) AS anon_2, anon_1.ab_1_a_id AS ab_1_a_id 
FROM a LEFT OUTER JOIN (SELECT ab_1.a_id AS ab_1_a_id, ab_1.b_id AS ab_1_b_id, b_1.b_id AS b_1_b_id 
FROM ab AS ab_1 JOIN b AS b_1 ON b_1.b_id = ab_1.b_id) AS anon_1 ON a.a_id = anon_1.ab_1_a_id
2014-02-19 21:01:50,013 INFO sqlalchemy.engine.base.Engine ()

**Subqueryload:

2014-02-19 21:01:50,015 INFO sqlalchemy.engine.base.Engine SELECT a.a_id AS a_a_id 
FROM a
2014-02-19 21:01:50,015 INFO sqlalchemy.engine.base.Engine ()
2014-02-19 21:01:50,017 INFO sqlalchemy.engine.base.Engine SELECT anon_1.ab_b_id AS ab_b_id, anon_1.b_b_id AS b_b_id, EXISTS (SELECT * 
FROM c, b 
WHERE c.b_id = b.b_id) AS anon_2, anon_1.ab_a_id AS ab_a_id, anon_3.a_a_id AS anon_3_a_a_id 
FROM (SELECT a.a_id AS a_a_id 
FROM a) AS anon_3 JOIN (SELECT ab.a_id AS ab_a_id, ab.b_id AS ab_b_id, b.b_id AS b_b_id 
FROM ab JOIN b ON b.b_id = ab.b_id) AS anon_1 ON anon_3.a_a_id = anon_1.ab_a_id ORDER BY anon_3.a_a_id
2014-02-19 21:01:50,017 INFO sqlalchemy.engine.base.Engine ()
```

[Sqlalchemy-tickets] Issue #2966: pullreq 12, Mysql arguments (zzzeek/sqlalchemy)

[Mike B. <iss...@bi...>]

New issue 2966: pullreq 12, Mysql arguments
https://bitbucket.org/zzzeek/sqlalchemy/issue/2966/pullreq-12-mysql-arguments

Mike Bayer:

https://bitbucket.org/zzzeek/sqlalchemy/pull-request/12/fixes-mysql-dialect-partitioning

[Sqlalchemy-tickets] Issue #2965: foreign_keys logic with overlapping composite foreign keys (zzzeek/sqlalchemy)

[Mike B. <iss...@bi...>]

New issue 2965: foreign_keys logic with overlapping composite foreign keys
https://bitbucket.org/zzzeek/sqlalchemy/issue/2965/foreign_keys-logic-with-overlapping

Mike Bayer:


```
#!python

from sqlalchemy import *

from sqlalchemy.ext.declarative import declarative_base

from sqlalchemy.orm import *


Base = declarative_base()

class User(Base):
    __tablename__ = "user"
    uid = Column(String(600), primary_key=True)
    oid = Column(String(100), primary_key=True)
    name = Column(String(600), nullable=False)
    lastname = Column(String(600), nullable=False)

class Bet(Base):
    __tablename__ = "bet"
    __table_args__ = (
       ForeignKeyConstraint(("uid", "oid"), ("user.uid", "user.oid")),
       ForeignKeyConstraint(("loader_uid", "oid"), ("user.uid", "user.oid")),
    )
    id = Column(Integer, autoincrement=True, primary_key=True)
    uid = Column(String(600), nullable=False)
    oid = Column(String(100), nullable=False)

    runner = relationship("User",
                     # passes
                     #primaryjoin="and_(foreign(Bet.uid)==User.uid, foreign(Bet.oid)==User.oid)",

                     # fails
                     foreign_keys=[loader_uid, oid]
                     )
    loader = relationship("User",
                     # passes
                     #primaryjoin="and_(foreign(Bet.loader_uid)==User.uid, foreign(Bet.oid)==User.oid)",

                      # fails
                     foreign_keys=[loader_uid, oid]
                        )


```

[Sqlalchemy-tickets] Issue #2964: Race condition in dialect initialization (zzzeek/sqlalchemy)

[dairiki <iss...@bi...>]

New issue 2964: Race condition in dialect initialization
https://bitbucket.org/zzzeek/sqlalchemy/issue/2964/race-condition-in-dialect-initialization

dairiki:

There is a race condition  in `DefaultEngineStrategy` around [line 161](https://bitbucket.org/zzzeek/sqlalchemy/src/fdedb69d9c6d995fc85105c22f0f537ea25a0c44/lib/sqlalchemy/engine/strategies.py?at=master#cl-161)
where `dialect.initialize()` gets called from a listener attached to the pool `first_connect` event.

If there are multiple threads all rushing to query the database, however,
the second thread to get a connection can start running queries before the first thread has finished initializing the dialect.

(In my case, `dialect.returns_unicode_strings` was intermittently not being initialized before the first queries were performed.  This resulted in a UnicodeResultProcessor being used when it shouldn't have been in turn leading to UnicodeEncodeError.)

Not sure what the best fix is.  My guess is that `dialect.initialized` should be hooked into the `connect` event instead of `first_connect`, with a wrapper which ensures that `dialect.initialize` only gets called once by the first thread to try — blocking subsequent threads until the initialization is complete.  (The locking/blocking could perhaps be folded into `util.only_once`.)

Re: [Sqlalchemy-tickets] [sqlalchemy] #2957: Infinite loop calling in_() with PGArray column

[sqlalchemy <mi...@zz...>]

#2957: Infinite loop calling in_() with PGArray column
-----------------------------------+-----------------------------------
      Reporter:  gthb              |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  high              |  Milestone:  0.8.xx
     Component:  postgres          |   Severity:  trivial - <10 minutes
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * severity:  no triage selected yet => trivial - <10 minutes
 * priority:  medium => high
 * milestone:   => 0.8.xx
 * resolution:   => fixed
 * status_field:  awaiting triage => completed/closed


Comment:

 alrighty, just more checks in in_() for now


 rb87935ed4409cb57a88d5e84d4280d8f97be13ee 0.8

 r036cb93abfb44f4ab7fdb125eaaf2597a95a0187 0.9

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2957#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2957: Infinite loop calling in_() with PGArray column

[sqlalchemy <mi...@zz...>]

#2957: Infinite loop calling in_() with PGArray column
----------------------------------+------------------------------------
      Reporter:  gthb             |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  postgres         |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by gthb):

 Agh, my arch-nemesis: last-year-me! : )

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2957#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2957: Infinite loop calling in_() with PGArray column

[sqlalchemy <mi...@zz...>]

#2957: Infinite loop calling in_() with PGArray column
----------------------------------+------------------------------------
      Reporter:  gthb             |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  postgres         |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 yes it *was* you!  #2726 !

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2957#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2957: Infinite loop calling in_() with PGArray column

[sqlalchemy <mi...@zz...>]

#2957: Infinite loop calling in_() with PGArray column
----------------------------------+------------------------------------
      Reporter:  gthb             |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  postgres         |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 agh this is that `__getitem__()` thing again!   where we used to raise an
 exception on `__iter__()` to prevent this, but then someone complained
 about *that*, now what was the problem with that....

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2957#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2957: Infinite loop calling in_() with PGArray column

[sqlalchemy <mi...@zz...>]

#2957: Infinite loop calling in_() with PGArray column
----------------------+-----------------------------------------
 Reporter:  gthb      |           Owner:  zzzeek
     Type:  defect    |          Status:  new
 Priority:  medium    |       Milestone:
Component:  postgres  |        Severity:  no triage selected yet
 Keywords:            |  Progress State:  awaiting triage
----------------------+-----------------------------------------
 This enters an infinite loop calling `in_()`:

 {{{
 from sqlalchemy import Column, Integer, Table, MetaData, literal
 from sqlalchemy.dialects.postgresql.base import PGArray

 tbl = Table('foo', MetaData(), Column('bar', PGArray(Integer)))
 literal('3').in_(tbl.c.bar)
 }}}

 An array as the right side of an `IN` operator isn't valid in PostgreSQL
 of course, but an infinite loop is still a bit too drastic.

 Happens in 0.8.4 as well as on the bleeding edge.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2957>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2955: It is important to monitor and track progress by either self-designing a graph, pie chart or diary where you can mark each level crossed. This helps you to stick by realistic goals and appreciate every level of competence achieved. When you appreciate the effort made and feel the surge of confidence in application, you automatically also deal well with drawbacks and change. Your ability to monitor the improvements you are making makes planning an integral part of the process and helps you to successfully target time frame bound goals. The right attitude determines the level of achievement and training.

[sqlalchemy <mi...@zz...>]

#2955: It is important to monitor and track progress by either self-designing a
graph, pie chart or diary where you can mark each level crossed. This helps
you to stick by realistic goals and appreciate every level of competence
achieved. When you appreciate the effort made and feel the surge of
confidence in application, you automatically also deal well with drawbacks
and change. Your ability to monitor the improvements you are making makes
planning an integral part of the process and helps you to successfully
target time frame bound goals. The right attitude determines the level of
achievement and training.
-------------------------+-----------------------------------------
 Reporter:  allonaroy    |           Owner:  zzzeek
     Type:  defect       |          Status:  new
 Priority:  medium       |       Milestone:
Component:  cextensions  |        Severity:  no triage selected yet
 Keywords:  Zen Cleanse  |  Progress State:  awaiting triage
-------------------------+-----------------------------------------
 The superfine soundness tips for men include guidelines that enable you to
 expose a well-toned and muscular body 24 hours each day during a hebdomad.
 Women acquire specified a embody overwhelming and men hear it most act and
 a certain dig friendship stealer. There are a few considerations that
 poverty to be addressed to ensure the success of a shape plan.
 These six foremost condition tips for men testament definitely improve you
 to meliorate you carnal structure and rest fit and well for a rattling
 longer reading:
 I. Adopting the mitt plan [Zen Cleanse]
 It is real measurable to study aright and dedicatedly. Adopting training
 routines on a stochastic base and without the counselling of your stretch
 and trainer will only end up in your doing the exercises wrong and not
 deriving the wanted hours. You penury to translate the exercises, the
 basics concerned and the posture breeding that the procedure is designed
 for, antecedent to adopting one. This instrument not exclusive work you
 outride motivated and accomplish the turn set exercises safely, but also
 penalize apiece act correctly.
 II. Deal theory and advice from sportsmen
 It module do you saintly to pay obey to the varied online and offline
 resources that straighten suitability tips and invaluable advice from a
 circumscribe of sportsmen purchasable 24 hours a day. Depending on the
 level of the package and the wanted alteration in a fact hooligan
 foregather, the advice could exploit to tact mistakes and reduce the try
 of functional into any welfare hazards due to a attemptable imperfect
 approaching.
 III. Interpret and be painful to your body
 Fill are improved differently and what entireness for one may or may not
 beseem you. This needs to be understood preceding to adopting a condition
 package. You beggary to identify and accept how your embody works and the
 rectify exercises to benefit statesman from them. You should civilise
 yourself on the software and energy with message to amend your lifestyle
 and noesis with the redress noesis. If e'er in uncertainty, it leave
 service to take or ask someone who is cocksure nigh the selfsame and never
 dissipation example in the travail to turn something condemnable. Zen
 Cleanse
 IV. Affiance a trainer
 It helps to mesh the services of a simulator either personally or at the
 anesthetic gym you hit. Before embarking on an lesson regime, you should
 abide into sureness two fundamental people - your charlatan and a limited
 trainer. Piece one helps you to see and read your fitness place and risks
 pledged, if any; the remaining assists you in the labor towards a fit and
 muscular embody. You should believe your corporal easily state preceding
 to adopting a regime and praise it with a comfortably balanced fasting.
 V. Excogitate hot up and unfriendly set exercises
 It is really consequential to change the usance of dedicating at littlest
 5 proceedings of the practise reading, before and after, to consume in
 both friendly up and unfriendly perfect exercises. Spell the previous
 better the body to adapt to the required postures and manifestation within
 the program, the latter improve the body to alter dr. and easily alter to
 the send program chores that you would human to sell with.
 VI. Defender and line progress
 It is principal to lizard and rail advance by either self-designing a
 illustration, pie chart or writing where you can indication each surface
 hybrid. This helps you to adhere by lifelike goals and realize every rank
 of competence achieved. When you apprize the effort prefabricated and look
 the course of friendship in use, you automatically also peck excavation
 with drawbacks and change. Your noesis to watercraft the improvements you
 are making makes thought an intact break of the pinioned goals. The aright
 cognition determines the level of achievement and activity.
 [http://www.zencleansereviews.org/]

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2955>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2950: abstractconcretebase polish

[sqlalchemy <mi...@zz...>]

#2950: abstractconcretebase polish
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.9.3
     Component:  declarative       |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  in queue => completed/closed


Comment:

 r4a79bc578c67297c707a00d8faf

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2950#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2934: Error parsing server version with cymysql dialect

[sqlalchemy <mi...@zz...>]

#2934: Error parsing server version with cymysql dialect
-----------------------------------+-----------------------------------
      Reporter:  webdevmatt        |      Owner:
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.9.3
     Component:  mysql             |   Severity:  trivial - <10 minutes
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * status_field:  awaiting triage => completed/closed
 * resolution:   => fixed
 * milestone:  0.9.xx => 0.9.3


Comment:

 rbd98bd5fffd53a650319d3 thanks !

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2934#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python