sqlalchemy-tickets Mailing List for SQLAlchemy (Page 60)
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...> - 2014-01-27 19:01:27
|
#2922: Metadata.reflect failed on different schema foreign key constraint
(postgresql)
-------------------------------------------+-------------------------------
Reporter: vrobin | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: no triage
Resolution: | selected yet
Progress State: needs questions answered | Keywords:
-------------------------------------------+-------------------------------
Changes (by zzzeek):
* status_field: awaiting triage => needs questions answered
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2922#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-27 18:58:50
|
#2922: Metadata.reflect failed on different schema foreign key constraint
(postgresql)
----------------------------------+------------------------------------
Reporter: vrobin | 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):
first, make sure you read:
http://docs.sqlalchemy.org/en/rel_0_9/dialects/postgresql.html#remote-
cross-schema-table-introspection
are you using an unusual search_path?
next, please run the attached test case. It includes your CREATE TABLE
and code verbatim, it works fine for me. Please alter it so that it
illustrates your problem.
Also note nothing has changed in 0.9 regarding how schemas are handled.
So I have a feeling your search path is not set appropriately for how
you're using the "schema" identifier here.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2922#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-27 18:47:24
|
#2921: backref relationships with cascade delete-orphan throw IntegrityError when
child is replaced
------------------------------+----------------------------------
Reporter: elmer | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.xx
Component: orm | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: needs tests |
------------------------------+----------------------------------
Changes (by zzzeek):
* priority: medium => high
* status_field: awaiting triage => needs tests
* component: (none) => orm
* severity: no triage selected yet => minor - half an hour
* milestone: => 0.9.xx
Comment:
Here's a patch that would the be the ORM's first foray into disabling
autoflush at certain places. Typically I never want to do this, but as
this is in the middle of attribute state being modified it might be
appropriate; but mostly making the case easy here is that all tests
continue to pass. i might be able to make this for 0.9.2.
{{{
#!diff
diff --git a/lib/sqlalchemy/orm/attributes.py
b/lib/sqlalchemy/orm/attributes.py
index e5f8550..08156a6 100644
--- a/lib/sqlalchemy/orm/attributes.py
+++ b/lib/sqlalchemy/orm/attributes.py
@@ -23,7 +23,7 @@ from .base import PASSIVE_NO_RESULT, ATTR_WAS_SET,
ATTR_EMPTY, NO_VALUE,\
NEVER_SET, NO_CHANGE, CALLABLES_OK, SQL_OK,
RELATED_OBJECT_OK,\
INIT_OK, NON_PERSISTENT_OK, LOAD_AGAINST_COMMITTED,
PASSIVE_OFF,\
PASSIVE_RETURN_NEVER_SET, PASSIVE_NO_INITIALIZE,
PASSIVE_NO_FETCH,\
- PASSIVE_NO_FETCH_RELATED, PASSIVE_ONLY_PERSISTENT
+ PASSIVE_NO_FETCH_RELATED, PASSIVE_ONLY_PERSISTENT,
NO_AUTOFLUSH
from .base import state_str, instance_str
@inspection._self_inspects
@@ -761,7 +761,8 @@ class ScalarObjectAttributeImpl(ScalarAttributeImpl):
"""
if self.dispatch._active_history:
- old = self.get(state, dict_, passive=PASSIVE_ONLY_PERSISTENT)
+ old = self.get(state, dict_, passive=PASSIVE_ONLY_PERSISTENT
+ | NO_AUTOFLUSH)
else:
old = self.get(state, dict_, passive=PASSIVE_NO_FETCH)
diff --git a/lib/sqlalchemy/orm/base.py b/lib/sqlalchemy/orm/base.py
index 577f9ff..b13396e 100644
--- a/lib/sqlalchemy/orm/base.py
+++ b/lib/sqlalchemy/orm/base.py
@@ -80,6 +80,13 @@ LOAD_AGAINST_COMMITTED =
util.symbol("LOAD_AGAINST_COMMITTED",
""", canonical=32
)
+NO_AUTOFLUSH = util.symbol("NO_AUTOFLUSH",
+"""loader callables should disable autoflush.
+
+.. versionadded:: 0.9.2
+
+""", canonical=64)
+
# pre-packaged sets of flags used as inputs
PASSIVE_OFF = util.symbol("PASSIVE_OFF",
"Callables can be emitted in all cases.",
diff --git a/lib/sqlalchemy/orm/strategies.py
b/lib/sqlalchemy/orm/strategies.py
index bd9b02d..14c2cf9 100644
--- a/lib/sqlalchemy/orm/strategies.py
+++ b/lib/sqlalchemy/orm/strategies.py
@@ -535,8 +535,9 @@ class LazyLoader(AbstractRelationshipLoader):
pending = not state.key
- # don't autoflush on pending
- if pending:
+ # don't autoflush on pending, or if
+ # NO_AUTOFLUSH is in passive flags
+ if pending or passive & attributes.NO_AUTOFLUSH:
q = q.autoflush(False)
if state.load_path:
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2921#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-27 16:21:36
|
#2922: Metadata.reflect failed on different schema foreign key constraint
(postgresql)
----------------------------------+------------------------------------
Reporter: vrobin | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by vrobin):
PS: problem verified with sqlalchemy v0.9.1
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2922#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-27 16:18:32
|
#2922: Metadata.reflect failed on different schema foreign key constraint
(postgresql)
----------------------+-----------------------------------------
Reporter: vrobin | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
----------------------+-----------------------------------------
A program that worked nicely on SQLAlchemy 0.8.X have begun to fail with
0.9.X upgrade.
The code that fails is this one:
{{{
engine = create_engine("postgresql+psycopg2://xxxxxx")
metadata = MetaData(bind=engine, schema="mymainschema")
metadata.reflect()
}}}
Error thrown is:
{{{
packages/sqlalchemy/dialects/postgresql/base.py", line 1690, in
get_table_oid
raise exc.NoSuchTableError(table_name)
sqlalchemy.exc.NoSuchTableError: tableinsecondarychema
}}}
Relashionship looks like (simplified):
{{{
CREATE TABLE mymainschema.myfirsttable
(
name character varying(255),
city_id character varying(255),
CONSTRAINT myfirsttable_pkey PRIMARY KEY (name),
CONSTRAINT fkdc7e8de5969fc80 FOREIGN KEY (city_id)
REFERENCES secondaryschema.tableinsecondarychema (city_code) MATCH
SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
}}}
I managed to workaround this problem with a quick and very dirty change in
get_table_oid function ( dialects/postgresql/base.py ):
{{{
if schema is not None:
schema = util.text_type(schema)
# CHANGE BEGIN
if table_name == 'tableinsecondarychema':
schema = u'secondaryschema'
# CHANGE END
s = sql.text(query).bindparams(table_name=sqltypes.Unicode)
}}}
But this is very ugly, and the problem looks like a bug. What do you think
about it? If you need more information, just let me know.
Regards,
Robin
PS: detailed trace of the problem
{{{
Traceback (most recent call last):
File "import.py", line 10, in <module>
from loid.connectors.xls_parser_monobloc import XlsReader
File "/home/jerry/mygreatapp/loid/connectors/xls_parser_monobloc.py",
line 35, in <module>
from xls_schedule_parser_base import \
File "/home/jerry/mygreatapp/loid/connectors/xls_parser_base.py", line
328, in <module>
from loid.dao import *
File "/home/jerry/mygreatapp/loid/dao.py", line 237, in <module>
metadata.reflect()
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 3015, in reflect
Table(name, self, **reflect_opts)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 355, in __new__
table._init(name, metadata, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 429, in _init
self._autoload(metadata, autoload_with, include_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 446, in _autoload
self, include_columns, exclude_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1107, in run_callable
return callable_(self, *args, **kwargs)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 308, in reflecttable
return insp.reflecttable(table, include_columns, exclude_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 555, in reflecttable
**reflection_options
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 355, in __new__
table._init(name, metadata, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 429, in _init
self._autoload(metadata, autoload_with, include_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 446, in _autoload
self, include_columns, exclude_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1107, in run_callable
return callable_(self, *args, **kwargs)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 308, in reflecttable
return insp.reflecttable(table, include_columns, exclude_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 555, in reflecttable
**reflection_options
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 355, in __new__
table._init(name, metadata, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 429, in _init
self._autoload(metadata, autoload_with, include_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 446, in _autoload
self, include_columns, exclude_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1107, in run_callable
return callable_(self, *args, **kwargs)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 308, in reflecttable
return insp.reflecttable(table, include_columns, exclude_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 555, in reflecttable
**reflection_options
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 355, in __new__
table._init(name, metadata, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 429, in _init
self._autoload(metadata, autoload_with, include_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 446, in _autoload
self, include_columns, exclude_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1107, in run_callable
return callable_(self, *args, **kwargs)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 308, in reflecttable
return insp.reflecttable(table, include_columns, exclude_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 563, in reflecttable
**reflection_options
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 355, in __new__
table._init(name, metadata, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 429, in _init
self._autoload(metadata, autoload_with, include_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/sql/schema.py", line 446, in _autoload
self, include_columns, exclude_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1107, in run_callable
return callable_(self, *args, **kwargs)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 308, in reflecttable
return insp.reflecttable(table, include_columns, exclude_columns)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 464, in reflecttable
for col_d in self.get_columns(table_name, schema, **tblkw):
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 277, in get_columns
**kw)
File "<string>", line 2, in get_columns
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 53, in cache
ret = fn(self, con, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/dialects/postgresql/base.py", line 1774, in
get_columns
info_cache=kw.get('info_cache'))
File "<string>", line 2, in get_table_oid
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/engine/reflection.py", line 53, in cache
ret = fn(self, con, *args, **kw)
File "/home/jerry/py-env/loid-env/local/lib/python2.7/site-
packages/sqlalchemy/dialects/postgresql/base.py", line 1690, in
get_table_oid
raise exc.NoSuchTableError(table_name)
sqlalchemy.exc.NoSuchTableError: tableinsecondarychema
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2922>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-27 14:58:45
|
#2921: backref relationships with cascade delete-orphan throw IntegrityError when
child is replaced
--------------------+-----------------------------------------
Reporter: elmer | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: (none) | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
--------------------+-----------------------------------------
In a two-table schema, with a parent table that holds a reference to a
child that may only have a single parent, assigning a new child to the
parent seems to break because of autoflushing. While the error is
avoidable by suppressing autoflushing, given that this is (for the user) a
single statement, it seems like something that should not happen.
Script to test this is enclosed (first run with 'initial' as argument,
then either 'break' or 'succeed'.
Software versions:
* SQLAlchemy version: 0.9.1
* Postgres version: 9.1.11
Complete log of queries emitted and final traceback from running the
'break' action of the attached script:
{{{
2014-01-27 15:47:32,906 INFO sqlalchemy.engine.base.Engine select
version()
2014-01-27 15:47:32,907 INFO sqlalchemy.engine.base.Engine {}
2014-01-27 15:47:32,909 INFO sqlalchemy.engine.base.Engine select
current_schema()
2014-01-27 15:47:32,909 INFO sqlalchemy.engine.base.Engine {}
2014-01-27 15:47:32,913 INFO sqlalchemy.engine.base.Engine show
standard_conforming_strings
2014-01-27 15:47:32,913 INFO sqlalchemy.engine.base.Engine {}
2014-01-27 15:47:32,914 INFO sqlalchemy.engine.base.Engine select relname
from pg_class c join pg_namespace n on n.oid=c.relnamespace where
n.nspname=current_schema() and relname=%(name)s
2014-01-27 15:47:32,915 INFO sqlalchemy.engine.base.Engine {'name':
u'a_child'}
2014-01-27 15:47:32,916 INFO sqlalchemy.engine.base.Engine select relname
from pg_class c join pg_namespace n on n.oid=c.relnamespace where
n.nspname=current_schema() and relname=%(name)s
2014-01-27 15:47:32,916 INFO sqlalchemy.engine.base.Engine {'name':
u'a_parent'}
2014-01-27 15:47:32,926 INFO sqlalchemy.engine.base.Engine BEGIN
(implicit)
2014-01-27 15:47:32,928 INFO sqlalchemy.engine.base.Engine SELECT
a_parent.id AS a_parent_id, a_parent.name AS a_parent_name,
a_parent.child_id AS a_parent_child_id
FROM a_parent
LIMIT %(param_1)s
2014-01-27 15:47:32,928 INFO sqlalchemy.engine.base.Engine {'param_1': 1}
/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py:537: SAWarning: Unicode type
received non-unicode bind param value.
processors[key](compiled_params[key])
2014-01-27 15:47:32,933 INFO sqlalchemy.engine.base.Engine INSERT INTO
a_child (location) VALUES (%(location)s) RETURNING a_child.id
2014-01-27 15:47:32,934 INFO sqlalchemy.engine.base.Engine {'location':
'Elsewhere'}
2014-01-27 15:47:32,937 INFO sqlalchemy.engine.base.Engine SELECT
a_child.id AS a_child_id, a_child.location AS a_child_location
FROM a_child
WHERE a_child.id = %(param_1)s
2014-01-27 15:47:32,937 INFO sqlalchemy.engine.base.Engine {'param_1': 15}
2014-01-27 15:47:32,940 INFO sqlalchemy.engine.base.Engine SELECT
a_parent.id AS a_parent_id, a_parent.name AS a_parent_name,
a_parent.child_id AS a_parent_child_id
FROM a_parent
WHERE %(param_1)s = a_parent.child_id
2014-01-27 15:47:32,940 INFO sqlalchemy.engine.base.Engine {'param_1': 15}
2014-01-27 15:47:32,945 INFO sqlalchemy.engine.base.Engine UPDATE a_parent
SET child_id=%(child_id)s WHERE a_parent.id = %(a_parent_id)s
2014-01-27 15:47:32,945 INFO sqlalchemy.engine.base.Engine {'child_id':
None, 'a_parent_id': 2}
2014-01-27 15:47:32,947 INFO sqlalchemy.engine.base.Engine ROLLBACK
Traceback (most recent call last):
File "test.py", line 70, in <module>
parent.child = child # Wrongness happens here
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 220, in __set__
instance_dict(instance), value, None)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 780, in set
value = self.fire_replace_event(state, dict_, value, old, initiator)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 801, in fire_replace_event
value = fn(state, value, previous, initiator or self._replace_token)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 1112, in
emit_backref_from_scalar_set_event
passive=PASSIVE_NO_FETCH)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 604, in append
self.set(state, dict_, value, initiator, passive=passive)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 764, in set
old = self.get(state, dict_, passive=PASSIVE_ONLY_PERSISTENT)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/attributes.py", line 579, in get
value = self.callable_(state, passive)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/strategies.py", line 505, in _load_for_state
return self._emit_lazyload(session, state, ident_key, passive)
File "<string>", line 1, in <lambda>
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/strategies.py", line 567, in _emit_lazyload
result = q.all()
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/query.py", line 2280, in all
return list(self)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/query.py", line 2391, in __iter__
self.session._autoflush()
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/session.py", line 1194, in _autoflush
util.raise_from_cause(e)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/util/compat.py", line 185, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/session.py", line 1184, in _autoflush
self.flush()
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/session.py", line 1879, in flush
self._flush(objects)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/session.py", line 1997, in _flush
transaction.rollback(_capture_exception=True)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/util/langhelpers.py", line 57, in __exit__
compat.reraise(exc_type, exc_value, exc_tb)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/session.py", line 1961, in _flush
flush_context.execute()
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/unitofwork.py", line 370, in execute
rec.execute(self)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/unitofwork.py", line 523, in execute
uow
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/persistence.py", line 59, in save_obj
mapper, table, update)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/orm/persistence.py", line 510, in
_emit_update_statements
execute(statement, params)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 664, in execute
return meth(self, multiparams, params)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/sql/elements.py", line 282, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 761, in _execute_clauseelement
compiled_sql, distilled_params
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 874, in _execute_context
context)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 1023, in _handle_dbapi_exception
exc_info
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/util/compat.py", line 185, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/base.py", line 867, in _execute_context
context)
File "/home/elmer/sqltest/env/local/lib/python2.7/site-
packages/sqlalchemy/engine/default.py", line 388, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.IntegrityError: (raised as a result of Query-invoked
autoflush; consider using a session.no_autoflush block if this flush is
occuring prematurely) (IntegrityError) null value in column "child_id"
violates not-null constraint
'UPDATE a_parent SET child_id=%(child_id)s WHERE a_parent.id =
%(a_parent_id)s' {'child_id': None, 'a_parent_id': 2}
}}}
Removing the delete-orphan AND single_parent=True from the backref
relationship avoids the error (but then removes the desired behavior of
removing childs that are no longer necessary).
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2921>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-26 00:03:39
|
#2920: Database dialect misdetected
-----------------------------------------+---------------------------------
Reporter: matthias-christian.ott | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone: 0.9.xx
Component: firebird | Severity: minor - half an
Resolution: | hour
Progress State: in queue | Keywords:
-----------------------------------------+---------------------------------
Changes (by zzzeek):
* status_field: awaiting triage => in queue
Comment:
OK, the "dialect" is based on server_version_info being "interbase" or
"firebird" and that version itself is based on
"fbconn.db_info(isc_info_firebird_version)". If isc_database_info is
more specific, then that should be used. However if the isc_database_info
feature is not available on older versions (which I'm assuming is the
case), the function shouldn't crash and should fall back to the old
behavior.
please send a pull request.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2920#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-25 23:10:18
|
#2920: Database dialect misdetected
-----------------------------------+---------------------------------------
Reporter: matthias- | Owner: zzzeek
christian.ott | Status: new
Type: defect | Milestone: 0.9.xx
Priority: medium | Severity: minor - half an hour
Component: firebird | Progress State: awaiting triage
Keywords: |
-----------------------------------+---------------------------------------
Currently SQLAlchemy detects the the SQL dialect of a database based on
the version string of the DBMS. Newer DBMS can manage databases with older
SQL dialects. Firebird can manage an older InterBase databases with SQL
dialect 1 for example. In one of my assigned projects we have database
with SQL dialect 1 and clients which depend upon this, but I can't execute
DDL statements on the database because SQLAlchemy detects the dialect as 2
based on the Firebird version number. One can determine the SQL dialect of
a database with isc_database_info and its respective Python wrappers more
reliably. I can provide a patch that corrects the detection mechanism, if
it gets accepted upstream.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2920>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-24 17:57:19
|
#2919: schematype support for typedecorator / PG ENUM
--------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone: 0.9.xx
Component: sql | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
--------------------+------------------------------------
figure out how users would know to follow this pattern, or how this can be
transparent:
{{{
#!python
import sqlalchemy as sa
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.dialects import postgresql
Base = declarative_base()
class MyEnum(sa.types.TypeDecorator, sa.types.SchemaType):
impl = postgresql.ENUM
def _set_parent(self, column):
self.impl._set_parent(column)
class Test(Base):
__tablename__ = 'test'
id = sa.Column(sa.Integer, primary_key=True)
enum_column = sa.Column(MyEnum('1', '2', '3', name='my_enum_type'))
engine = sa.create_engine('postgresql://scott:tiger@localhost/test',
echo=True)
Base.metadata.create_all(engine)
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2919>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-23 19:51:22
|
#2918: polymorphic aliasing failure when using trivial column subclass
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: highest | Milestone: 0.9.xx
Component: orm | Severity: major - 1-3 hours
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in progress => completed/closed
Comment:
r15b23c7f71c0ca8c526db2794b2c459c848, also the tests have been backported
to 0.8 in r2866577231511a9d38ab9c7c42ce68b.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2918#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-23 19:13:32
|
#2918: polymorphic aliasing failure when using trivial column subclass
------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.9.xx
Component: orm | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in progress |
------------------------------+-------------------------------
Comment (by zzzeek):
it's annotations, here's a test case:
{{{
#!python
from sqlalchemy import Column
class MySpecialColumn(Column):
pass
col = MySpecialColumn('x', String)
binary_1 = col == 5 # caches col.comparator, col.comparator.expr == col
c2 = col._annotate({"x": "foo"}) # uses Annotated, not AnnotatedColumn,
as base class
binary_2 = c2 == 5 # fails to use a new col.comparator, uses the old one
with col and missing annotatinos
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2918#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-23 18:19:00
|
#2918: polymorphic aliasing failure when using trivial column subclass
---------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.9.xx
Component: orm | Severity: major - 1-3 hours
Keywords: | Progress State: in progress
---------------------+------------------------------------
this seems like an 0.9 regression
{{{
#!python
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class A(Base):
__tablename__ = 'a'
id = Column(Integer, primary_key=True)
class MySpecialColumn(Column):
pass
class B(A):
__tablename__ = 'b'
id = Column(ForeignKey('a.id'), primary_key=True)
x = MySpecialColumn(String)
s = Session()
print s.query(A).join(B).filter(B.x == 'asdf')
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2918>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 21:03:14
|
#2917: support "down" adaptions? (was: sqlalchemy.dialects.mysql.base.ENUM is not
adaptable to sqlalchemy.sql.sqltypes.Enum)
-----------------------------------+-------------------------------
Reporter: jpcalderone | Owner:
Type: defect | Status: closed
Priority: medium | Milestone: 0.9.xx
Component: mysql | Severity: major - 1-3 hours
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Comment (by jpcalderone):
Thanks!
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2917#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 20:39:15
|
#2917: support "down" adaptions? (was: sqlalchemy.dialects.mysql.base.ENUM is not
adaptable to sqlalchemy.sql.sqltypes.Enum)
-----------------------------------+-------------------------------
Reporter: jpcalderone | Owner:
Type: defect | Status: closed
Priority: medium | Milestone: 0.9.xx
Component: mysql | Severity: major - 1-3 hours
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* status_field: awaiting triage => completed/closed
* resolution: => fixed
* severity: no triage selected yet => major - 1-3 hours
* milestone: => 0.9.xx
Comment:
r1732414076677e8fb8413 includes down adaption tests and fixes to MySQL,
SQLite
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2917#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 19:45:32
|
#2917: support "down" adaptions? (was: sqlalchemy.dialects.mysql.base.ENUM is not
adaptable to sqlalchemy.sql.sqltypes.Enum)
----------------------------------+------------------------------------
Reporter: jpcalderone | Owner:
Type: defect | Status: new
Priority: medium | Milestone:
Component: mysql | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
I made some alterations to test.sql.test_types:AdaptTest.test_adapt_method
to also run through all possible "down" adaptions, it currently does all
potential "up" adaptions. Most of the additional failures are of the
same nature as this one:
{{{
FAILURE: <class 'sqlalchemy.dialects.sqlite.base.DATETIME'> -> <class
'sqlalchemy.sql.sqltypes.DateTime'> __init__() got an unexpected keyword
argument 'storage_format'
FAILURE: <class 'sqlalchemy.dialects.mysql.base.ENUM'> -> <class
'sqlalchemy.sql.sqltypes.Enum'> __init__() got an unexpected keyword
argument 'strict'
FAILURE: <class 'sqlalchemy.dialects.sqlite.base.DATE'> -> <class
'sqlalchemy.sql.sqltypes.Date'> object() takes no parameters
FAILURE: <class 'sqlalchemy.dialects.sqlite.base.TIME'> -> <class
'sqlalchemy.sql.sqltypes.Time'> __init__() got an unexpected keyword
argument 'storage_format'
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2917#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 19:28:42
|
#2917: support "down" adaptions? (was: sqlalchemy.dialects.mysql.base.ENUM is not
adaptable to sqlalchemy.sql.sqltypes.Enum)
----------------------------------+------------------------------------
Reporter: jpcalderone | Owner:
Type: defect | Status: new
Priority: medium | Milestone:
Component: mysql | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
`strict` is not ignored, it is used by `mysql.ENUM.bind_processor`. It's
tested in mysql.test_types:EnumSetTest.test_enum which fails if you
comment that line out, as currently the ENUM is adapted to a new object
with the same type.
The issue here is related to what I would characterize as unintended use
of the `adapt()` method - this method is until now only intended for "up"
adaptions, that is from a more generic type to a dialect-specific type,
and not for a "down" adaption from a specific type to a more general.
That use case doesn't exist within SQLAlchemy internals.
What's special about "strict" here as opposed to all the other custom
keyword arguments that other MySQL types and other types from other
dialects include, is that it is dialect-specific but also affects the
runtime type-coercion behavior. That's why this special adapt() method
exists - because adapt() is already only used to produce a new type object
that's appropriate for run-time type coercion.
in the vast majority of cases elsewhere I've just looked at, types have
predictable argument signatures because all keyword arguments are
ultimately explicitly within the `__init__` method of the type itself or a
superclass; the default adapt() method looks at `__bases__` to get at
these additional arguments. `Enum` is special because it starts out with
`*varargs`, and Python 2 doesn't provide Py3K's nice "keyword-only
arguments" feature that we'd otherwise be using here.
We have a suite that tests all possible legal "up" adaptions but not
"down" adaptions. That would need to be added. Autocode should be able
to fix this right now just by using the adapt() of the general type:
{{{
Enum.adapt(meta.tables['foo'].columns['bar'].type, Enum)
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2917#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 17:53:59
|
#2917: sqlalchemy.dialects.mysql.base.ENUM is not adaptable to
sqlalchemy.sql.sqltypes.Enum
-------------------------+-----------------------------------------
Reporter: jpcalderone | Owner:
Type: defect | Status: new
Priority: medium | Milestone:
Component: mysql | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
Given a MySQL table like:
{{{
#!sql
CREATE TABLE foo ( bar enum('false','true') );
}}}
the reflected `foo.bar` column has a type of
`sqlalchemy.dialects.mysql.base.ENUM`. Attempting to use the `adapt`
method results in a `TypeError` due to bad arguments being passed to
`SchemaType.__init__`:
{{{
>>> meta.tables['foo'].columns['bar'].type.adapt(Enum)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "SQLAlchemy-0.9.2dev-py2.7-linux-
x86_64.egg/sqlalchemy/dialects/mysql/base.py", line 1194, in adapt
return sqltypes.Enum.adapt(self, impltype, **kw)
File "SQLAlchemy-0.9.2dev-py2.7-linux-
x86_64.egg/sqlalchemy/sql/sqltypes.py", line 1145, in adapt
**kw
File "SQLAlchemy-0.9.2dev-py2.7-linux-
x86_64.egg/sqlalchemy/sql/sqltypes.py", line 1110, in __init__
SchemaType.__init__(self, **kw)
TypeError: __init__() got an unexpected keyword argument 'strict'
>>>
}}}
It looks like git rev 2692238f may have introduced this by changing the
signature of `SchemaType.__init__` from `**kw` to something a little more
restricted.
Consider `strict` was ignored even before 2692238f I wonder if
`sqlalchemy.dialects.mysql.base.ENUM.adapt` should just be deleted to let
the inherited implementation be used instead.
Encountered while trying the sqlacodegen project. Bug first reported
against that project:
https://bitbucket.org/agronholm/sqlacodegen/issue/9/get-typeerror-
__init__-got-an-unexpected
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2917>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 01:31:37
|
#1672: supply "detect" option for passive_updates
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.x.xx
Component: orm | Severity: major - 1-3 hours
Resolution: wontfix | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => wontfix
* status_field: awaiting triage => completed/closed
Comment:
this is really not needed at all, mutable primary keys are already a rare
edge case, and then the cases where "passive_updates=False" actually
creates a problem on an FK database is very rare, essentially there's one
test in test_naturalpks that illustrates this. there's not an easy way
to detect this condition in any case as on MySQL is per-table. not
really worth it.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1672#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 01:15:53
|
#1277: "row switch" concept is broken
-----------------------------------+--------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone: blue sky
Component: orm | Severity: refactor - over two days
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+--------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: on hold => completed/closed
Comment:
the issue here of emitting DELETE before INSERT is addressed by the patch
in #2501. However, it requires that the feature be turned on explicitly.
this is likely OK because DELETE before INSERT raises all kinds of
unresolvable conflicts - it needs to be something someone would turn on.
the feature needs tests and polish but is mostly ready to go.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1277#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 01:07:14
|
#2501: the DELETE before INSERT problem
------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.xx
Component: orm | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: needs tests |
------------------------------+---------------------------------------
Comment (by zzzeek):
here's a test that illustrates the feature working against the primary
key, a change to the patch coming will handle this:
{{{
#!python
from sqlalchemy import create_engine
from sqlalchemy import Column, Integer, String, Float, UniqueConstraint,
ForeignKey
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import Session, relationship, backref
from sqlalchemy.orm.dependency import OneToManyDP, attributes
Base = declarative_base()
class ParentEntity(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
name = Column(String)
__mapper_args__ = {
"maintain_unique_attributes": [("id",)]
}
engine = create_engine('sqlite://', echo=True)
Base.metadata.create_all(engine)
sess = Session(engine)
p1 = ParentEntity(id=1, name='p1')
sess.add(p1)
sess.commit()
p2 = ParentEntity(id=1, name='p2')
sess.delete(p1)
sess.add(p2)
sess.commit()
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:21>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 00:37:21
|
#2720: use Cython for C extensions?
-----------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: blue sky
Component: cextensions | Severity: very major - up to 2 days
Resolution: wontfix | Keywords:
Progress State: completed/closed |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => wontfix
* status_field: not decided upon => completed/closed
Comment:
I think we're sticking with our hand-written C extensions for now -
they're very well tested and certainly the existence of pypy as a viable
option makes it hard to justify a rework the whole approach.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2720#comment:35>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 00:34:47
|
#2727: ProgrammingError when autoload from PostgreSQL (Amazon Redshift)
-----------------------------------+----------------------------------
Reporter: ashkop | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone: 0.x.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: on hold => completed/closed
Comment:
the issue is pushed out to the redshift-sqlalchemy dialect, the docs have
been updated to link to it in ee1f4d21037690ad996c. the dialect for now
skips index reflection.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2727#comment:14>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 00:30:24
|
#814: with_lockmode() doesn't allow db-native lockmodes
-----------------------------------+----------------------------------
Reporter: jek | Owner: zzzeek
Type: defect | Status: closed
Priority: low | Milestone: 0.x.xx
Component: orm | Severity: minor - half an hour
Resolution: fixed | Keywords: orm
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: awaiting triage => completed/closed
Comment:
with_lockmode() has been superseded by with_for_update(), which is
available with the same calling interface on both select() and Query. It
accepts "read", "nowait" as flags as well as "of". so we've exposed the
SQL level detail of "FOR UPDATE" and there's not really any translation
anymore. with_lockmode() itself translates the string codes into those
flags which are then interpreted by the dialect.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/814#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-22 00:26:29
|
#2701: date/datetime-specific operators
-----------------------------------+---------------------------------------
Reporter: tisdall | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.x.xx
Component: sql | Severity: very major - up to 2 days
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: needs questions answered => completed/closed
Comment:
#2769 is the ticket for this issue.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2701#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2014-01-21 18:15:11
|
#2916: possible numeric regression on 0.9.1
-----------------------------------+-------------------------------
Reporter: zzzeek | Owner:
Type: defect | Status: closed
Priority: highest | Milestone: 0.9.xx
Component: mssql | Severity: major - 1-3 hours
Resolution: worksforme | Keywords:
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => worksforme
* status_field: in queue => completed/closed
Comment:
this is due to the column being actually DECIMAL on the DB side. the
MSSQL dialect in 0.9 specifically has a pyodbc float type and it does not
check for a type handler. We can check for pyodbc sending us the
"Decimal" class here in the result processor; some dialects, like that of
psycopg2, are smart enough to look at the incoming "coltype" to determine
the correct handling, while others (most?) are not (e.g. MySQLdb sends us
integer codes but we don't have a lookup for them).
So in this case the behavior of using a Float to receive Numeric/DECIMAL
values is undefined; it will vary by backend. In MSSQL's case it's just
changed. I'd rather not get into trying to support mismatches like this
consistently in all cases, it's better to just use the correct type.
here's a test just for record:
{{{
#!python
import sys
import cdecimal
sys.modules["decimal"] = cdecimal
from sqlalchemy import *
e = create_engine("mssql://scott:tiger@ms_2005", echo='debug')
conn = e.connect()
trans = conn.begin()
t = Table('t', MetaData(), Column('data', Numeric(10, 5)))
t.create(conn)
conn.execute(t.insert().values(data="45.17"))
t2 = Table('t', MetaData(), Column('data', Float()))
print(conn.execute(t2.select()).fetchall())
t3 = Table('t', MetaData(), Column('data', Numeric(asdecimal=False)))
print(conn.execute(t3.select()).fetchall())
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2916#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
186 messages has been excluded from this view by a project administrator.
