sqlalchemy-tickets Mailing List for SQLAlchemy (Page 88)
Brought to you by:
zzzeek
Menu
▾
▴
sqlalchemy-tickets — trac tickets and updates forwarded to this list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(174) |
Apr
(50) |
May
(71) |
Jun
(129) |
Jul
(113) |
Aug
(141) |
Sep
(82) |
Oct
(142) |
Nov
(97) |
Dec
(72) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(159) |
Feb
(213) |
Mar
(156) |
Apr
(151) |
May
(58) |
Jun
(166) |
Jul
(296) |
Aug
(198) |
Sep
(89) |
Oct
(133) |
Nov
(150) |
Dec
(122) |
| 2008 |
Jan
(144) |
Feb
(65) |
Mar
(71) |
Apr
(69) |
May
(143) |
Jun
(111) |
Jul
(113) |
Aug
(159) |
Sep
(81) |
Oct
(135) |
Nov
(107) |
Dec
(200) |
| 2009 |
Jan
(168) |
Feb
(109) |
Mar
(141) |
Apr
(128) |
May
(119) |
Jun
(132) |
Jul
(136) |
Aug
(154) |
Sep
(151) |
Oct
(181) |
Nov
(223) |
Dec
(169) |
| 2010 |
Jan
(103) |
Feb
(209) |
Mar
(201) |
Apr
(183) |
May
(134) |
Jun
(113) |
Jul
(110) |
Aug
(159) |
Sep
(138) |
Oct
(96) |
Nov
(116) |
Dec
(94) |
| 2011 |
Jan
(97) |
Feb
(188) |
Mar
(157) |
Apr
(158) |
May
(118) |
Jun
(102) |
Jul
(137) |
Aug
(113) |
Sep
(104) |
Oct
(108) |
Nov
(91) |
Dec
(162) |
| 2012 |
Jan
(189) |
Feb
(136) |
Mar
(153) |
Apr
(142) |
May
(90) |
Jun
(141) |
Jul
(67) |
Aug
(77) |
Sep
(113) |
Oct
(68) |
Nov
(101) |
Dec
(122) |
| 2013 |
Jan
(60) |
Feb
(77) |
Mar
(77) |
Apr
(129) |
May
(189) |
Jun
(155) |
Jul
(106) |
Aug
(123) |
Sep
(53) |
Oct
(142) |
Nov
(78) |
Dec
(102) |
| 2014 |
Jan
(143) |
Feb
(93) |
Mar
(35) |
Apr
(26) |
May
(27) |
Jun
(41) |
Jul
(45) |
Aug
(27) |
Sep
(37) |
Oct
(24) |
Nov
(22) |
Dec
(20) |
| 2015 |
Jan
(17) |
Feb
(15) |
Mar
(34) |
Apr
(55) |
May
(33) |
Jun
(31) |
Jul
(27) |
Aug
(17) |
Sep
(22) |
Oct
(26) |
Nov
(27) |
Dec
(22) |
| 2016 |
Jan
(20) |
Feb
(24) |
Mar
(23) |
Apr
(13) |
May
(17) |
Jun
(14) |
Jul
(31) |
Aug
(23) |
Sep
(24) |
Oct
(31) |
Nov
(23) |
Dec
(16) |
| 2017 |
Jan
(24) |
Feb
(20) |
Mar
(27) |
Apr
(24) |
May
(28) |
Jun
(18) |
Jul
(18) |
Aug
(23) |
Sep
(30) |
Oct
(17) |
Nov
(12) |
Dec
(12) |
| 2018 |
Jan
(27) |
Feb
(23) |
Mar
(13) |
Apr
(19) |
May
(21) |
Jun
(29) |
Jul
(11) |
Aug
(22) |
Sep
(14) |
Oct
(9) |
Nov
(24) |
Dec
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 18:04:47
|
#2161: Py3k support for the C extension
-------------------------------+-------------------------------
Reporter: ged | Owner: pjenvey
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: cextensions | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: needs review |
-------------------------------+-------------------------------
Comment (by zzzeek):
I am 100% with you that cython is better but the existing C extensions
should be ported in place in any case. I think the only sscanf stuff we
have is with the date parsers, and the code for this is already there in
the attached patch.
The code here is literally 95% done it just needs to be checked for
correctness and tested.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2161#comment:23>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 17:47:41
|
#2161: Py3k support for the C extension
-------------------------------+-------------------------------
Reporter: ged | Owner: pjenvey
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: cextensions | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: needs review |
-------------------------------+-------------------------------
Comment (by claudiofreire):
The biggest API difference is that everything is unicode now.
So, while in py2 parsing a datetime is easily done with sscanf, in py3 you
must first convert to ASCII, and catch errors in the process. There's a
LOT of boilerplate to do that, and Cython has it all pretty well cooked,
hiding all that boilerplate that is indeed quite different between py2 and
py3.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2161#comment:22>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 17:41:59
|
#2161: Py3k support for the C extension
-------------------------------+-------------------------------
Reporter: ged | Owner: pjenvey
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: cextensions | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: needs review |
-------------------------------+-------------------------------
Comment (by zzzeek):
Reimplementing in Cython is "fine" as a long term goal, however to get our
existing C extensions to work in py3k should be a far smaller task. Not
just in terms of coding. More importantly, in terms of tests and proven
stability; the C extensions we have right now are very widely used and
tested in thousands if not tens of thousands of installations. If we
rewrite C exts from scratch using a new system, we throw that maturity out
the window and start all over again.
Adding C extensions for small functions here and there isn't really going
to get us much in terms of performance, and I'm more or less -1 on the
#2720 improvement as far as attribute access, the ratio of code
verbosity/complexity to performance gain is too high in that case. In
order to break out of what are very diminishing returns right now, we'd
really need to reconstruct the entire core and ORM using C throughout.
This would definitely be more of a Cython project as it would be
unworkable otherwise, but that's a large and distant undertaking. Right
now, Pypy continues to be developed with funding, suggesting the irony
that the longer we do nothing, the more progress is actually made towards
us getting all the speed improvements via pypy for free.
As far as this issue, while it's a small task, it's been sitting here for
literally two years, I'll likely be digging in to learn the API
differences and try to get this in for 0.9.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2161#comment:21>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 17:28:10
|
#2772: overflow counter not handled on particular exception case
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: highest | Milestone: 0.8.xx
Component: pool | Severity: major - 1-3 hours
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: needs tests => completed/closed
Comment:
the pool redesign just the other day makes this issue easier to account
for, have ported part of it to 0.8.
r4a9d88b1cf1ba674f13b8e9c173aabd13b82dc36 0.8
rf390639bf1a7a5a2a47bcd6df7106cf5855a44c1 master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2772#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 17:03:36
|
#2161: Py3k support for the C extension
-------------------------------+-------------------------------
Reporter: ged | Owner: pjenvey
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: cextensions | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: needs review |
-------------------------------+-------------------------------
Comment (by claudiofreire):
Check out #2720. Although re-implementing in Cython does reduce
performance a tiny bit (10% or less in all checks I performed for
cprocessors), it gives free Py3k compatibility.
Is it worth paying that performance price (I'd think so)?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2161#comment:20>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-04 14:01:49
|
#2772: overflow counter not handled on particular exception case
---------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: pool | Severity: major - 1-3 hours
Keywords: | Progress State: needs tests
---------------------+------------------------------------
need to write mock tests for this, the idea is:
{{{
#!python
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
from time import sleep
from traceback import print_exc
from sqlalchemy import create_engine
import logging
logging.basicConfig()
logger = logging.getLogger('sqlalchemy.pool')
logger.setLevel(logging.DEBUG)
connection_string = "mysql://<hidden connection string>"
engine = create_engine(connection_string, pool_recycle=1)
print("open and close a connection so that it is returned to the pool")
conn = engine.pool.connect()
assert engine.pool.checkedout() == 1
conn.close()
assert engine.pool.checkedout() == 0
sleep(1)
raw_input("""
because of pool_recycle, the connection in pool should have expired by now
now - break DNS so that connect() will fail
you can easily do this by adding the hostname in
/etc/hosts and pointing it to 127.0.0.1
press enter when ready
""")
try:
conn = engine.pool.connect()
except:
print_exc()
print
if engine.pool.checkedout() > 0:
print("BUG reproduced: checkedout() should have returned 0")
else:
raise Exception("failed to reproduce")
else:
raise Exception("connection succeeded - did you break DNS?")
}}}
suggested patch in 0.8 is:
{{{
#!diff
-- SQLAlchemy-0.8.1/SQLAlchemy-0.8.1/lib/sqlalchemy/pool.py 2013-06-21
15:44:01.000000000 -0700
+++ SQLAlchemy-0.8.1.fbar.fix.leak/SQLAlchemy-0.8.1/lib/sqlalchemy/pool.py
2013-06-21 17:47:12.000000000 -0700
@@ -423,7 +423,11 @@
self._echo = _echo = pool._should_log_debug()
try:
rec = self._connection_record = pool._do_get()
- conn = self.connection =
self._connection_record.get_connection()
+ try:
+ conn = self.connection =
self._connection_record.get_connection()
+ except:
+ _finalize_fairy(None, rec, pool, None, _echo)
+ raise
rec.fairy = weakref.ref(
self,
lambda ref: _finalize_fairy and \
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2772>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-03 15:30:33
|
#2771: Full Unicode support on MySQL
-----------------------------------+------------------------------------
Reporter: kondi | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone:
Component: mysql | Severity: no triage selected yet
Resolution: worksforme | Keywords:
Progress State: completed/closed |
-----------------------------------+------------------------------------
Changes (by zzzeek):
* status: new => closed
* component: cextensions => mysql
* resolution: => worksforme
* status_field: awaiting triage => completed/closed
Comment:
without further [http://www.sqlalchemy.org/participate.html#bugs detail]
given, this issue would appear to have nothing to do with SQLAlchemy - the
"charset" parameter are straight pass-thrus to the database API and the
database itself, SQLAlchemy has no awareness of a "!LookupError" and by
default defers all unicode behaviors to the DBAPI and database itself in
the case of MySQL. A stack trace would help to reveal the source of this
issue.
sample test passes without issue:
{{{
#!python
from sqlalchemy import *
e = create_engine("mysql://scott:tiger@localhost/test", echo=True)
m = MetaData()
t = Table('t', m, Column('data', String(50)), mysql_engine='InnoDB',
mysql_charset='utf8mb4')
m.create_all(e)
e.execute(t.insert(), data="hello world")
}}}
output:
{{{
CREATE TABLE t (
data VARCHAR(50)
)ENGINE=InnoDB CHARSET=utf8mb4
2013-07-03 11:28:18,033 INFO sqlalchemy.engine.base.Engine ()
2013-07-03 11:28:18,049 INFO sqlalchemy.engine.base.Engine COMMIT
2013-07-03 11:28:18,049 INFO sqlalchemy.engine.base.Engine INSERT INTO t
(data) VALUES (%s)
2013-07-03 11:28:18,049 INFO sqlalchemy.engine.base.Engine ('hello
world',)
2013-07-03 11:28:18,051 INFO sqlalchemy.engine.base.Engine COMMIT
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2771#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-03 05:19:09
|
#2771: Full Unicode support on MySQL
-------------------------+-----------------------------------------
Reporter: kondi | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: cextensions | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
We have a new server build with Python 2.7.5 / SqlAlchemy 0.8 / MySQL
5.5.31. We store a variety of Unicode strings in various tables, all
using utf8 encoding.
Today I've discovered that MySQL utf8 doesn't support UTF-8 encoding, but
only the code points represented as one, two, and three byte characters,
which omits a large subset of Unicode. As of version 5.5.3, MySQL
supports the entire Unicode set with a new encoding 'utf8mb4'. However,
we are unable to select this character set with SqlAlchemy. I have just
carefully traced an attempt to store a string containing the Unicode code
points '\ud83d' and '\ude02', only to see the utf8-encoded result
truncated to the substring preceding the first of these supplemental
characters, producing this warning:
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:320:
Warning: Incorrect string value: '\xF0\x9F\x98\xB7' for column 'text' at
row 1
Attempts to create tables with:
__table_args__ = {'mysql_engine': 'InnoDB', 'mysql_charset': 'utf8mb4'}
fail with:
LookupError: unknown encoding: utf8mb4
Has anyone had success using utf8mb4, or for that matter any approach to
store the full Unicode character set with SqlAlchemy / MySQL? Or are
there plans to enhance SqlAlchemy to support full Unicode with MySQL?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2771>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-02 22:26:19
|
#2768: bound parameters in UPDATE..FROM are subject to mis-ordering
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
r9c5a13f0495c0f175b6c0fbd1124b6bedf232b2f 0.8
rb1e1bf8e674f8175f33a03d master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2768#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-02 22:12:31
|
#2764: Make sqlite handle BIGINT
-----------------------------------+-----------------------------------
Reporter: rstuart4133 | Owner: zzzeek
Type: defect | Status: closed
Priority: low | Milestone: 0.8.xx
Component: sqlite | Severity: trivial - <10 minutes
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-----------------------------------
Changes (by zzzeek):
* status: new => closed
* type: enhancement => defect
* resolution: => fixed
* severity: no triage selected yet => trivial - <10 minutes
* status_field: in queue => completed/closed
Comment:
r2180cf44e5856bc4be6cf5b125b8672b2158ffa2 0.8
r1fb6c4a33d67229847aafd45c7 master
thanks!
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2764#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-02 22:04:06
|
#2761: allow non-property objects to work with declarative string resolution
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: high | Milestone: 0.8.xx
Component: orm | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: needs tests => completed/closed
Comment:
r761414a07be34aaebf76e7 0.8
r0e219f2eff8954e20d8e3 master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2761#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-02 17:19:48
|
#2770: attempt to streamline/improve execution options flow
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.9.0
Component: engine | 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:
rd3d10c982c8a44c85a0114c has us ready to let dialects make better use of
execution options.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2770#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-02 01:55:27
|
#2770: attempt to streamline/improve execution options flow
------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: engine | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by zzzeek):
work has begun at r60eee33bca6f815932ef11074da0c358668f82c8
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2770#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-01 20:54:21
|
#2720: new C extensions for attribute accessing
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: cextensions | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+---------------------------------------
Comment (by claudiofreire):
So, I finally got back to this. Pyrex has no Py3 support, so Cython's the
only choice.
cprocessors.int_to_bool becomes a tad slower, going from 0.84s (py2) to
0.94s (py3) for 10M iterations. Is that in line with your previous
results?
The same code with cython and py2 stays at 0.84s, so I'm wondering if the
slowness is a py3 thing instead of a cython thing.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:20>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-07-01 16:08:43
|
#2770: attempt to streamline/improve execution options flow
-------------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: engine | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
-------------------------+------------------------------------
notes:
{{{
#!diff
diff --git a/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
b/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
index c8d8e98..42d3766 100644
--- a/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
+++ b/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
@@ -99,9 +99,11 @@ class FBDialect_kinterbasdb(FBDialect):
cursor.execute(statement, parameters or [])
def do_rollback(self, dbapi_connection):
+ # TODO: look in dbapi_connection._memos here for instructions
dbapi_connection.rollback(self.retaining)
def do_commit(self, dbapi_connection):
+ # TODO: look in dbapi_connection._memos here for instructions
dbapi_connection.commit(self.retaining)
def create_connect_args(self, url):
diff --git a/lib/sqlalchemy/dialects/oracle/cx_oracle.py
b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
index e013799..58a0227 100644
--- a/lib/sqlalchemy/dialects/oracle/cx_oracle.py
+++ b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
@@ -829,6 +829,7 @@ class OracleDialect_cx_oracle(OracleDialect):
def do_prepare_twophase(self, connection, xid):
result = connection.connection.prepare()
+ # TODO: use .memo for this
connection.info['cx_oracle_prepared'] = result
def do_rollback_twophase(self, connection, xid, is_prepared=True,
@@ -840,11 +841,13 @@ class OracleDialect_cx_oracle(OracleDialect):
if not is_prepared:
self.do_commit(connection.connection)
else:
+ # TODO: use .memo for this
oci_prepared = connection.info['cx_oracle_prepared']
if oci_prepared:
self.do_commit(connection.connection)
def do_recover_twophase(self, connection):
+ # TODO: use .memo for this
connection.info.pop('cx_oracle_prepared', None)
dialect = OracleDialect_cx_oracle
diff --git a/lib/sqlalchemy/engine/base.py b/lib/sqlalchemy/engine/base.py
index 2d9f3af..a87f308 100644
--- a/lib/sqlalchemy/engine/base.py
+++ b/lib/sqlalchemy/engine/base.py
@@ -70,6 +70,10 @@ class Connection(Connectable):
self._has_events = _has_events or engine._has_events
self._echo = self.engine._should_log_info()
+
+ # TODO: see if the same dialect hook below can also get fired
+ # for this, or maybe at the engine level and dialects can add a
listener
+ # perhaps
if _execution_options:
self._execution_options =\
engine._execution_options.union(_execution_options)
@@ -200,6 +204,9 @@ class Connection(Connectable):
"""
c = self._clone()
c._execution_options = c._execution_options.union(opt)
+
+ # TODO: see if a dialect hook can be made here,
+ # do this in that hook
if 'isolation_level' in opt:
c._set_isolation_level()
return c
diff --git a/lib/sqlalchemy/pool.py b/lib/sqlalchemy/pool.py
index dcf3d9e..2d8756f 100644
--- a/lib/sqlalchemy/pool.py
+++ b/lib/sqlalchemy/pool.py
@@ -322,6 +322,11 @@ class _ConnectionRecord(object):
exec_once(self.connection, self)
pool.dispatch.connect(self.connection, self)
+ # TODO: add a new collection here per checkout
+ @util.memoized_property
+ def _memos(self):
+ return {} # clear/remove on checkin
+
@util.memoized_property
def info(self):
return {}
@@ -409,9 +414,13 @@ def _finalize_fairy(connection, connection_record,
pool, ref, echo):
if connection_record is not None:
connection_record.fairy = None
+
+ # TODO: change this, make some kind of symmetric system
+ # where dialects can put any number of setup/teardown things
if connection_record.finalize_callback:
connection_record.finalize_callback(connection)
del connection_record.finalize_callback
+
if pool.dispatch.checkin:
pool.dispatch.checkin(connection, connection_record)
pool._return_conn(connection_record)
@@ -465,6 +474,7 @@ class _ConnectionFairy(object):
in subsequent instances of :class:`.ConnectionFairy`.
"""
+ # TODO: this never fires
try:
return self._connection_record.info
except AttributeError:
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2770>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-30 23:57:02
|
#2763: retaining=True flag on firebird dialects should be configurable
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: highest | Milestone: 0.8.xx
Component: firebird | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in progress => completed/closed
Comment:
rcc299b2d1cb50c035aaf8e6324d8d7cad12436c6 master
r868da0c281904aa66cde9e 0.8
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2763#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-30 20:00:09
|
#2750: Inconsistent behavior for polymorphic queries
-----------------------------------+----------------------------------
Reporter: schlamar | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: orm | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Comment (by zzzeek):
and more fixes, since the value might not be there on an UPDATE, in
rd4b850fa6bb7bc9bfe4430bb11612e8ce699a49c
r715d6cf3d10a71
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2750#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-30 15:22:22
|
#2750: Inconsistent behavior for polymorphic queries
-----------------------------------+----------------------------------
Reporter: schlamar | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: orm | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Comment (by zzzeek):
better tests in r6ece305692399db8266fb028a9fe5f8a1af0295b /
r1d67b2a23364b482
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2750#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-30 15:14:53
|
#2750: Inconsistent behavior for polymorphic queries
-----------------------------------+----------------------------------
Reporter: schlamar | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: orm | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: needs tests => completed/closed
Comment:
it's a warning, as apps can successfully work using this technique even
though it's ill-advised, but also it might be possible to have systems
where the incoming query and outgoing value are different, even though in
that case we usually don't have a polymorphic_setter involved.
read7d9a680911606820dd9c6688fc7131b1a911e 0.8
r3b24ccaf28fd85a6e54a master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2750#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-29 03:55:05
|
#2740: remove the ::interval cast in the postgresql dialect
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone: 0.8.xx
Component: postgres | Severity: major - 1-3 hours
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* status_field: in queue => completed/closed
* resolution: => fixed
* severity: minor - half an hour => major - 1-3 hours
* milestone: 0.9.0 => 0.8.xx
Comment:
rd875f677a3f9c20d49d2 master
r169c88c7a5bc1a6de9 0.8
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2740#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-29 01:38:50
|
#2769: preliminary date operation support
-------------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: sql | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
-------------------------+------------------------------------
We can get support for "date2 - date1" pretty easily for most backends at
this point, now that we have full control of operators. The most
straightforward way might be just to create a SQL construct called
"DateSubtract" or something like that, returning an Interval as the return
type.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2769>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-28 15:51:46
|
#2757: Firebird types are not translated correctly
-----------------------------------+----------------------------------
Reporter: rstuart4133 | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: firebird | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
rf57fc6836f47598362247045c296c5b2c0182b6d 0.8
rbccf8ff5b1b17fd093308b40e726051256ec14ae master
thanks for the patch!
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2757#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-28 15:39:59
|
#2766: backslashes in HSTORE
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: postgres | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
confirmed the issue is local to our own parser, psycopg2's behaves
correctly.
r69179e009c2dcf71945415d455765b98ecd89fe4 0.8
r04b66bc5e7b8e8e93d78e9c70a533cd39e367aaf master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2766#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-28 14:22:09
|
#2768: bound parameters in UPDATE..FROM are subject to mis-ordering
---------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in queue |
---------------------------+----------------------------------
Changes (by zzzeek):
* severity: major - 1-3 hours => minor - half an hour
Comment:
OK very easy:
{{{
#!diff
diff --git a/lib/sqlalchemy/sql/compiler.py
b/lib/sqlalchemy/sql/compiler.py
index 0afcdfa..7770c7f 100644
--- a/lib/sqlalchemy/sql/compiler.py
+++ b/lib/sqlalchemy/sql/compiler.py
@@ -1606,8 +1606,6 @@ class SQLCompiler(engine.Compiled):
extra_froms = update_stmt._extra_froms
- colparams = self._get_colparams(update_stmt, extra_froms)
-
text = "UPDATE "
if update_stmt._prefixes:
@@ -1617,6 +1615,8 @@ class SQLCompiler(engine.Compiled):
table_text = self.update_tables_clause(update_stmt,
update_stmt.table,
extra_froms, **kw)
+ colparams = self._get_colparams(update_stmt, extra_froms)
+
if update_stmt._hints:
dialect_hints = dict([
(table, hint_text)
}}}
more of a test:
{{{
d1 = DefaultDialect()
d1.positional = True
c1 = stmt.compile(dialect=d1)
print c1
print c1.positiontup
compiled = stmt.compile(dialect=mysql.dialect())
print compiled
print compiled.positiontup
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2768#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-28 14:09:20
|
#2768: bound parameters in UPDATE..FROM are subject to mis-ordering
--------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: sql | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
--------------------+------------------------------------
this is a funny one:
{{{
#!python
from sqlalchemy.sql import table, column, select
from sqlalchemy.dialects import mysql
t1 = table('t1', column('x'))
t2 = table('t2', column('y'), column('z'))
subq = select([t2]).where(t2.c.y == 7).alias()
stmt = t1.update().values(x=5).where(t1.c.x == subq.c.z)
compiled = stmt.compile(dialect=mysql.dialect())
# default impl, UPDATE..FROM . y follows x
print stmt
# mysql impl, UPDATE A, B, x follows y
print compiled
# but still getting y follows x
print compiled.positiontup
}}}
that is:
{{{
UPDATE t1 SET x=:x FROM (SELECT t2.y AS y, t2.z AS z
FROM t2
WHERE t2.y = :y_1) AS anon_1 WHERE t1.x = anon_1.z
UPDATE t1, (SELECT t2.y AS y, t2.z AS z
FROM t2
WHERE t2.y = %s) AS anon_1 SET t1.x=%s WHERE t1.x = anon_1.z
['x', u'y_1']
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2768>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
186 messages has been excluded from this view by a project administrator.
