sqlalchemy-tickets Mailing List for SQLAlchemy (Page 74)
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-10-20 02:32:09
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by zzzeek):
yup so adding this to CreateTable/DropTable etc. and then into the
appropriate alembic.op as discussed would be all you need;
create_all()/drop_all() etc. and the ddl.py sequence isn't used by
alembic.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-19 15:53:19
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by remyroy):
My personal use case is for migration. I'm currently migrating from using
sqlalchemy-migrate to using alembic for schema migration. I have a bunch
of databases for a single application which are in different states
because they use different version of the same application which use
different schema.
In some cases, I would need to create tables, columns, indexes if they do
no already exists or drop tables, columns, indexes if they already exists
without alembic aborting. I believe the IF EXISTS/IF NOT EXISTS constructs
to be well suited for this need.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-19 06:46:02
|
#2838: render_literal_bindparam() naively calls cached_bind_processor
---------------------------+-------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.0
Component: sql | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
---------------------------+-------------------------------
Comment (by zzzeek):
initial idea is in the ticket_2838 branch at
rbc5834d6431663ad2a03677af87dd96a8de923e1. we'll move the whole concept
of literal bind rendering into the type system.
the String type will also need to determine if encoding is needed here.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2838#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-19 06:18:33
|
#2842: The recipe "Storing/Using Enumerations" does not function in SQLite
-----------------------------------+------------------------------------
Reporter: rgg | Owner: zzzeek
Type: enhancement | Status: closed
Priority: low | Milestone:
Component: utils | Severity: no triage selected yet
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: awaiting triage => completed/closed
Comment:
this is due to #2838.
removing the naive calling of cached_bind_processor:
{{{
#!diff
diff --git a/lib/sqlalchemy/sql/compiler.py
b/lib/sqlalchemy/sql/compiler.py
index 22906af..4c5700f 100644
--- a/lib/sqlalchemy/sql/compiler.py
+++ b/lib/sqlalchemy/sql/compiler.py
@@ -954,9 +954,9 @@ class SQLCompiler(Compiled):
def render_literal_bindparam(self, bindparam, **kw):
value = bindparam.value
- processor = bindparam.type._cached_bind_processor(self.dialect)
- if processor:
- value = processor(value)
+ #processor = bindparam.type._cached_bind_processor(self.dialect)
+ #if processor:
+ # value = processor(value)
return self.render_literal_value(value, bindparam.type)
def render_literal_value(self, value, type_):
}}}
recipe works again.
the regression in 0.9 is due to the greater usage of
render_literal_bindparam() introduced in #2742.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2842#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-19 06:06:24
|
#487: "case-insensitive" (and "case-sensitive"?) SQL operations
--------------------------------+------------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: blue sky
Component: sql | Severity: major - 1-3 hours
Resolution: wontfix | Keywords: case insensitive comparisons
Progress State: |
completed/closed |
--------------------------------+------------------------------------------
Changes (by zzzeek):
* status: assigned => closed
* resolution: => wontfix
* status_field: in queue => completed/closed
Comment:
closing this for these reasons:
1. the patch here is seven years old and the code is entirely unusable.
2. "case insensitive" operations can't reliably be achieved using LOWER()
or UPPER(), as these do not accommodate unicode case folding - see
http://www.w3.org/International/wiki/Case_folding.
3. the general idea of working an expression like `func.lower()` into
string comparison operations is simple, a simple recipe has been added at
UsageRecipes/StringComparisonFilter.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/487#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-19 00:02:52
|
#2716: table.tometadata(metadata) should copy column.info dictionary instead of
referencing same dictionary
-----------------------------------+----------------------------------
Reporter: kentbower | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.9.0
Component: schema | 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:
there's info dictionaries on all `SchemaItem` objects, so the change in
r73669c7284548d0e5ab2147f66174 adds copying for all of these dictionaries
which previously weren't transferred at all.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2716#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 23:36:42
|
#2803: HSTORE docs fix
-----------------------------------+-----------------------------------
Reporter: jonathan | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: documentation | Severity: trivial - <10 minutes
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* severity: no triage selected yet => trivial - <10 minutes
* status_field: awaiting triage => completed/closed
Comment:
I did my best here, the term "in-place" is meaningful so I left that in,
tried to introduce the word "event" so that the reader gets the idea that
this has to do with events. I can't prevent every user from not
understanding, though.
rbb6df3f45f0d06e0b364ea06cb9e17c04513e192 0.8
r71e043aaae1ff9cbf0597846b4 master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2803#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 23:25:44
|
#2233: Python callable column default does not reflect, not documented
-----------------------------------+----------------------------------
Reporter: guest | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone: 0.8.xx
Component: documentation | Severity: minor - half an hour
Resolution: fixed | Keywords: reflection, defaults
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
add a new section "limitations of reflection" including this and other
potential issues.
r4187fb2811639c6391f8c55 0.8
r7108605f697fc53f3b03a90ed4e9e05777d4a6cc master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2233#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 23:05:02
|
#2844: remove the substring call from PG calls to pg_get_expr()
-----------------------------------+-----------------------------------
Reporter: zzzeek | 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
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
r5ae388b0773cb95f5e4e9487433a0e81e5bf8cd3 0.8
rfff90799098bd14ea68c158 master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2844#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 19:37:19
|
#2841: MySQL doesn't support MATCH, INITIALLY, or DEFERRED
-----------------------------------+----------------------------------
Reporter: uijllji | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: mysql | Severity: minor - half an hour
Resolution: fixed | Keywords: mysql, ddl, schema
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* status_field: in queue => completed/closed
Comment:
cf1ac72bca8b0bc28e09cdb4cdf052bcf82e5076 warning + tests + docs in 0.8
ca02882c6a0d66562d86bf55d5449a04825fa354 error + tests + docs in master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2841#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 19:37:03
|
#2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases
-----------------------------------+-------------------------------
Reporter: kashif | Owner:
Type: defect | Status: closed
Priority: medium | Milestone: 0.9.0
Component: mysql | Severity: major - 1-3 hours
Resolution: fixed | Keywords: mysql deferrable
Progress State: completed/closed |
-----------------------------------+-------------------------------
Changes (by zzzeek):
* status: reopened => closed
* resolution: => fixed
* status_field: in progress => completed/closed
Comment:
cf1ac72bca8b0bc28e09cdb4cdf052bcf82e5076 warning + tests + docs in 0.8
ca02882c6a0d66562d86bf55d5449a04825fa354 error + tests + docs in master
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2721#comment:9>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 18:42:46
|
#2721: SQLAlchemy leaks the deferrable keyword in FKs for mysql databases
------------------------------+-------------------------------
Reporter: kashif | Owner:
Type: defect | Status: reopened
Priority: medium | Milestone: 0.9.0
Component: mysql | Severity: major - 1-3 hours
Resolution: | Keywords: mysql deferrable
Progress State: in progress |
------------------------------+-------------------------------
Changes (by zzzeek):
* status: closed => reopened
* status_field: completed/closed => in progress
* resolution: fixed =>
* severity: trivial - <10 minutes => major - 1-3 hours
* milestone: 0.8.xx => 0.9.0
Comment:
I'm going to have to give you a hard change on this one for 0.9.
Silently ignoring keywords that make no sense on a MySQL FK, or in the
case of MATCH actually *break* MySQL (see "important" at
https://dev.mysql.com/doc/refman/5.5/en/create-table-foreign-keys.html) is
not a good solution here, if a user puts deferrable or initially on their
FK and doesn't know about MySQL's FK behavior they get silent failure
here. see #2841.
I think going forward, if you are knowingly disabling FKs on your MySQL
database, you should use this recipe to disable generation of FKs:
{{{
#!python
from sqlalchemy.ext.compiler import compiles
from sqlalchemy.schema import ForeignKeyConstraint
@compiles(ForeignKeyConstraint, "mysql")
def process(element, compiler, **kw):
return "" # or blank out "deferrable"
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2721#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 18:42:35
|
#2841: MySQL doesn't support MATCH, INITIALLY, or DEFERRED
---------------------------+----------------------------------
Reporter: uijllji | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: mysql | Severity: minor - half an hour
Resolution: | Keywords: mysql, ddl, schema
Progress State: in queue |
---------------------------+----------------------------------
Comment (by zzzeek):
well yeah, this is a total crapshow. we have a precedent of ignoring
"deferrable" already set up in #2721. But the approach in #2721 is really
only valid when someone is using SET FOREIGN_KEY_CHECKS=0.
So i think we need to rethink this entirely. I'd like to invalidate
#2721 and give that user an entirely different path for his FK situation.
DEFERRABLE and INITIALLY will be let through again, causing MySQL to fail
(it fails, I checked). MATCH will totally raise an error. in 0.8,
nothing changes but everything warns.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2841#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 18:14:11
|
#2839: MySQL dialect's get_foreign_keys doesn't parse options
---------------------------+-------------------------------
Reporter: uijllji | Owner:
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: mysql | Severity: major - 1-3 hours
Resolution: | Keywords: foreign keys
Progress State: in queue |
---------------------------+-------------------------------
Comment (by zzzeek):
well yeah, this is a total crapshow. we have a precedent of ignoring
"deferrable" already set up in #2721. But the approach in #2721 is really
only valid when someone is using SET FOREIGN_KEY_CHECKS=0.
So i think we need to rethink this entirely. I'd like to invalidate
#2721 and give that user an entirely different path for his FK situation.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2839#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 16:34:06
|
#2847: interpret a Query in Query as aliased(ent, q.subquery()) ?
-------------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.0
Component: orm | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
-------------------------+------------------------------------
Basically, if you were to say
sess.query(some_query).join(some_other_query) it would act like this:
{{{
#!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)
bs = relationship("B")
class B(Base):
__tablename__ = 'b'
id = Column(Integer, primary_key=True)
a_id = Column(Integer, ForeignKey('a.id'))
e = create_engine("sqlite://", echo=True)
Base.metadata.create_all(e)
sess = Session(e)
sess.add_all([A(bs=[B(), B()]), A(bs=[B()])])
def foo_thing(q):
ent = q.column_descriptions[0]['expr']
return aliased(ent, q.subquery())
q1 = sess.query(A)
q2 = sess.query(B)
print sess.query(foo_thing(q1)).join(foo_thing(q2)).all()
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2847>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 16:26:26
|
#2845: Query.group_by() ignores arguments
-----------------------------------+------------------------------------
Reporter: dwt | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone:
Component: orm | Severity: no triage selected yet
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: awaiting triage => completed/closed
Comment:
consolidating under #2846
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2845#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 16:26:10
|
#2797: expression-level many-to-one comparison
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.9.xx
Component: orm | Severity: minor - half an hour
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: in queue => completed/closed
Comment:
consolidating under #2846
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2797#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 16:25:55
|
#1328: query() should interpret a many-to-one relation() as an entity?
-----------------------------------+----------------------------------
Reporter: guest | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.x.xx
Component: orm | Severity: minor - half an hour
Resolution: duplicate | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: not decided upon => completed/closed
Comment:
consolidating under #2846
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1328#comment:10>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 16:25:21
|
#2846: many-to-one relationship interpretation by query
-------------------------+------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: enhancement | Status: new
Priority: high | Milestone: 0.9.xx
Component: orm | Severity: major - 1-3 hours
Keywords: | Progress State: in queue
-------------------------+------------------------------------
consolidating #1328, #2797, #2845 as these are all dealing with the same
thing from different angles.
SomeClass.some_m2o, which refers to OtherEntity as a many-to-one, would be
interpreted:
1. for `sess.query(SomeClass.some_m2o)` as `sess.query(OtherEntity)`
2. for `sess.query(SomeClass).filter(SomeClass.some_m2o == OtherEntity)`
as `filter(SomeClass.other_entity_id == OtherEntity.id)`
3. for `sess.query(SomeClass).order_by(SomeClass.some_m2o),
group_by(SomeClass.some_m2o)`, as `order_by/group_by
SomeClass.other_entity_id`
4. as is currently the case,
`sess.query(SomeClass).filter(SomeClass.some_m2o == other_entity)`
compares to other_entity.id
any other `query.something(SomeClass.m2o..something)` type requests should
get put here.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2846>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-18 10:36:54
|
#2845: Query.group_by() ignores arguments
--------------------+-----------------------------------------
Reporter: dwt | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: orm | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
--------------------+-----------------------------------------
Hi there,
I just spent an hour to debug why group_by was ignored for a query I was
transforming, so I gather it's worth it to spend some more time to report
a bug. We are using version 0.7.x so there may have been changes since,
but I wasn't yet able to invest the time to create a testcase that
reproduces this.
Here's what happens. Using the ORM I transform a query like this:
{{{
query =
statistics.track_items_for_topics_in_date_range_query([topic],
early_cutoff, late_cutoff)
from sqlalchemy.sql import func
query = query.with_entities(TrackItem.question_id,
TrackItem.user_id,
func.max(TrackItem.creation_time).label('max_creation_time'))
query = query.group_by(TrackItem.question, TrackItem.user)
}}}
The problem/workaround is to not use the objects in the group_by() but
instead the _id suffixes to tell sqlalchemy that it should group by the
ids instead.
Now what happens if you don't know/see this is that the group_by() call is
just ignored and the query is the exact same query after the call as it
was before hand.
Which is, uhm, a bit hard to debug. :)
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2845>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 23:43:48
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by zzzeek):
I can enthusiastically make IF [NOT] EXISTS a part of the ddl.py sequence,
that is the sequence which is pretty much used only by methods like
create_all()/drop_all()/create()/drop(), if I understand exactly what use
case it serves - this because a feature is best designed when I have some
idea what it's used for. Perhaps it's useful if someone wants to capture
a create_all() sequence as a SQL string?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 22:07:48
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by remyroy):
Would it be acceptable to implement this checkexists, ie the use of IF
EXISTS/IF NOT EXISTS for DDL, along side the current checkfirst even
though they serve the same purpose?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 19:46:57
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by zzzeek):
well the downside is that different database backends would now take an
entirely different approach for create/drop, which would remove a certain
consistency of approach we've had for many years in this area, as well as
place a new and unproven feature at the center of a very stable and
critical function. if performance is a concern (which it's generally
not) I was thinking we could instead amend dialects to include a new
"has_tables" function, that could query the existence of many tables all
at once, providing a performance improvement that applies to any backend
(at least as long as they support querying for multiple table names at
once via system views). the case where most tables exist already would
otherwise mean there'd be a lot of fully rendered CREATE TABLE statements
being parsed for no reason.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 18:46:43
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
------------------------------+-------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Comment (by remyroy):
Would it make sense to merge the currently implemented checkfirst logic
with the IF EXISTS/IF NOT EXISTS implementation? What I mean is that for
dialects who supports IF EXISTS/IF NOT EXISTS for a specific object type,
no introspection would be done whenever checkfirst=True, only the CREATE
or DROP statement would be issued with the proper IF EXISTS/IF NOT EXISTS
vocabulary. That would save some roundtrip to the database for those who
support IF EXISTS/IF NOT EXISTS.
I would also rename "checkfirst" to "checkexists" and update the
documentation accordingly.
Would it be a good idea to include a long list of supports_[statement |
"[create|drop]_[object type]" ]_checkexists attributes for each dialect
class? I believe some DBMS have mixed IF EXISTS/IF NOT EXISTS support for
different object types and for CREATE or DROP and other statements. For
instance, PostgreSQL 8.2 supports DROP TABLE IF EXISTS but does not
support CREATE TABLE IF NOT EXISTS or ALTER TABLE DROP COLUMN IF EXISTS
while PostgreSQL 9.2 supports DROP TABLE IF EXISTS, CREATE TABLE IF NOT
EXISTS and ALTER TABLE DROP COLUMN IF EXISTS.
I might be able to work on this and get you a pull request with
documentation and tests.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 04:16:59
|
#2844: remove the substring call from PG calls to pg_get_expr()
----------------------+----------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: postgres | Severity: trivial - <10 minutes
Keywords: | Progress State: in queue
----------------------+----------------------------------------
this code seems to be from postgresql itself but it's truncating to 128
characters for display purposes. we need the whole string.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2844>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
186 messages has been excluded from this view by a project administrator.
