sqlalchemy-tickets Mailing List for SQLAlchemy (Page 75)
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-17 02:55:16
|
#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 |
------------------------------+-------------------------------
Changes (by zzzeek):
* priority: low => medium
* status_field: awaiting triage => in queue
* severity: no triage selected yet => major - 1-3 hours
* milestone: => 0.9.xx
Comment:
this is always something people can help along via pull request, we've
been doing well with those lately
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 02:26:12
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
----------------------------------+------------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: low | Milestone:
Component: schema | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by remyroy):
This would be quite useful for migration tools like Alembic for instance.
see https://bitbucket.org/zzzeek/alembic/issue/151/if-exists-if-not-
exists-directives
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-17 02:17:24
|
#2843: Support for IF EXISTS/IF NOT EXISTS DDL constructs
-------------------------+-----------------------------------------
Reporter: remyroy | Owner: zzzeek
Type: enhancement | Status: new
Priority: low | Milestone:
Component: schema | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
IF EXISTS and IF NOT EXISTS are already part of many DBMSs DDL vocabulary.
They have many use cases which are highly useful in some situations.
For instance, creating a table if it does not already exists or dropping a
column if it exists.
It would be nice to have those directives with standard SQLAlchemy DDL
methods. I guess they could be implemented using the native support for
DBMSs that support them or with some introspection for those that do not.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2843>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-16 08:09:20
|
#2842: The recipe "Storing/Using Enumerations" does not function in SQLite
-------------------------+-----------------------------------------
Reporter: rgg | Owner: zzzeek
Type: enhancement | Status: new
Priority: low | Milestone:
Component: utils | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
The recipe "Storing/Using Enumerations", described in
http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/ does not function
in SQLite using the latest SQLAlchemy version (from the repository).
It fails when it tries to create the CHECK constraint associated to the
Enum field. The constraint receives the values associated to the enum
symbols, but requires the symbols, and it fails when trying to get the
values of the symbols.
In PostgreSQL (which uses a native ENUM type) the recipe works ok.
I suppose it will fail in all databases which don't have a native Enum
type, but I have verified the failure only on SQLite.
Regards,
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2842>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 23:12:29
|
#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 |
---------------------------+----------------------------------
Changes (by zzzeek):
* priority: medium => high
* milestone: => 0.8.xx
* component: cextensions => mysql
* severity: no triage selected yet => minor - half an hour
* status_field: awaiting triage => in queue
Comment:
So I'm torn between CompileError and warning with or without ignoring it.
someone who wants to set up MATCH for other backends would otherwise have
to do a conditional DDL here, but if someone actually needs MATCH to be
significant probably has to do that anyway.
how about CompileError on 0.9 and warning on 0.8? it is possible
existing applications are relying upon current behavior.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2841#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 23:08:49
|
#2841: MySQL doesn't support MATCH, INITIALLY, or DEFERRED
----------------------------------+------------------------------------
Reporter: uijllji | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: cextensions | Severity: no triage selected yet
Resolution: | Keywords: mysql, ddl, schema
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
wow headslap, what a nasty behavior
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2841#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 23:07:16
|
#2840: Support for PostgreSQL's SMALLSERIAL type
-----------------------------------+----------------------------------
Reporter: grv87 | Owner: zzzeek
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.9.0
Component: postgres | Severity: minor - half an hour
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 => minor - half an hour
* milestone: => 0.9.0
Comment:
version 9.2. ra5dc173ea6735c2b0877c77
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2840#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 22:49:45
|
#2840: Support for PostgreSQL's SMALLSERIAL type
----------------------------------+------------------------------------
Reporter: grv87 | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
Assuming you're referring to the DDL generation of BIGSERIAL/SERIAL.
Postgresql 8.x doesnt have SMALLSERIAL so am trying to identify the
specific version where this becomes avaiable.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2840#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 22:34:10
|
#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 |
---------------------------+-------------------------------
Changes (by zzzeek):
* priority: low => high
* milestone: => 0.8.xx
* severity: no triage selected yet => major - 1-3 hours
* status_field: awaiting triage => in queue
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2839#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 20:55:43
|
#2841: MySQL doesn't support MATCH, INITIALLY, or DEFERRED
--------------------------------+-----------------------------------------
Reporter: uijllji | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: cextensions | Severity: no triage selected yet
Keywords: mysql, ddl, schema | Progress State: awaiting triage
--------------------------------+-----------------------------------------
MySQL does not support foreign key options of MATCH, INITIALLY, or
DEFERRED. See:
https://dev.mysql.com/doc/refman/5.5/en/create-table-foreign-keys.html,
find for 'Important'
MATCH causes later options such as ON UPDATE and ON DELETE to be silently
ignored.
So if a user sets MATCH, INIITALLY, or DEFERRED in their
ForeignKeyConstraint object, their schema will differ without any warning.
I therefore propose the MySQL dialect throw a CompileError if those
options are specified.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2841>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 20:44:14
|
#2840: Support for PostgreSQL's SMALLSERIAL type
-------------------------+-----------------------------------------
Reporter: grv87 | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
SQLAlchemy supports PostgreSQL's BIGSERIAL type, but not SMALLSERIAL. I
propose to add SMALLSERIAL (which actually means sequenced column of type
smallint).
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2840>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-15 20:24:20
|
#2839: MySQL dialect's get_foreign_keys doesn't parse options
--------------------------+-----------------------------------------
Reporter: uijllji | Owner:
Type: defect | Status: new
Priority: low | Milestone:
Component: mysql | Severity: no triage selected yet
Keywords: foreign keys | Progress State: awaiting triage
--------------------------+-----------------------------------------
MySQL dialect's get_foreign_keys method always gives `onupdate` and
`ondelete` values of `None`. It also searches for `match`, but MySQL
doesn't implement MATCH.
The regex parsing searches for MATCH with a \w+ for the value, then ON
DELETE and ON UPDATE. I believe the \w+ will go on to match the ON DELETE
and ON UPDATE as well.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2839>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-14 20:13:54
|
#2817: apply the autoquoting logic of mysql.ENUM to mysql.SET
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner:
Type: defect | Status: closed
Priority: high | Milestone: 0.9.0
Component: mysql | Severity: minor - half an hour
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* status_field: in queue => completed/closed
* resolution: => fixed
* milestone: 0.8.xx => 0.9.0
Comment:
this is 0.9 only as it produces deprecation warnings and some differences
in behavior.
r92534dc8f30d173deaa122
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2817#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-14 18:57:54
|
#2825: Index.unique should be only True or False, index=True on Column breaking
this
-----------------------------------+-----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.8.xx
Component: schema | Severity: trivial - <10 minutes
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+-----------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* severity: minor - half an hour => trivial - <10 minutes
* status_field: needs tests => completed/closed
Comment:
r621c22ca31eb395c4c47e313a00b1708b76d0017 0.8
r78a38967c4ad94194308f77f60a922236cd75 0.9
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2825#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-14 18:40:41
|
#2835: set index attributes before events are called
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: highest | 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: needs tests => completed/closed
Comment:
r9d38ed33400adf3ba8fdf3af49
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2835#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-14 14:56:01
|
#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
Keywords: | Progress State: in queue
--------------------+------------------------------------
I think we need a new method on type that's specific to rendering a type
for literal SQL. At the moment, a string type on an encoding backend can
pass in a bytes into render_literal_value (see
test.sql.test_types:EnumTest.test_mock_engine_no_prob using Oracle backend
on python3). We're working around this by re-decoding the bytes in the
method, but more elaborate bind processor schemes will need to be aware of
literal SQL and naturally this should be type-based in any case.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2838>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 20:55:28
|
#2836: supply distinct within subq eager load when we see that the inner query
isn't loading a distinct field
-----------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: closed
Priority: high | Milestone: 0.9.0
Component: orm | 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:
rf00544a589d5002ddf0146706c4ba675 master
r28a349135792a2f8e94fc0892cb61280 0.8
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2836#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 18:10:52
|
#2515: mysqlconnector cannot override settings
-----------------------------------+-----------------------------------
Reporter: srathbun | Owner:
Type: enhancement | Status: closed
Priority: medium | Milestone: 0.8.xx
Component: mysql | Severity: trivial - <10 minutes
Resolution: fixed | Keywords: mysqlconnector
Progress State: completed/closed |
-----------------------------------+-----------------------------------
Changes (by zzzeek):
* status: new => closed
* milestone: 0.x.xx => 0.8.xx
* resolution: => fixed
* status_field: on hold => completed/closed
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2515#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 18:10:40
|
#2515: mysqlconnector cannot override settings
------------------------------+-----------------------------------
Reporter: srathbun | Owner:
Type: enhancement | Status: new
Priority: medium | Milestone: 0.x.xx
Component: mysql | Severity: trivial - <10 minutes
Resolution: | Keywords: mysqlconnector
Progress State: on hold |
------------------------------+-----------------------------------
Comment (by zzzeek):
the defaults just needed to be set correctly:
r0cea9fd61c59b68dd7e027bec92a67ebbea239fc 0.8
366e74b1bef36d384da4da8ff68751d68ba078f6 0.9
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2515#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 17:54:51
|
#2183: support "ON DELETE/UPDATE" in Foreign Key Reflection
------------------------------+-------------------------------
Reporter: guest | Owner: zzzeek
Type: enhancement | Status: new
Priority: high | Milestone: 0.9.0
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in progress |
------------------------------+-------------------------------
Changes (by zzzeek):
* priority: medium => high
* status_field: awaiting triage => in progress
* milestone: 0.x.xx => 0.9.0
Comment:
we already do this for MySQL. For Postgresql we have
https://github.com/zzzeek/sqlalchemy/pull/34. so the spec here is that
it's part of "options" in the FK spec.
next part, this is fairly straightforward, link up those options in
reflection.py where we generate the `ForeignKeyConstraint`.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2183#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 00:30:02
|
#2837: fix logging to truncate large textual/binary values
------------------------------+-------------------------------
Reporter: jonathan | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.8.xx
Component: engine | Severity: major - 1-3 hours
Resolution: | Keywords:
Progress State: in queue |
------------------------------+-------------------------------
Changes (by zzzeek):
* severity: no triage selected yet => major - 1-3 hours
* component: documentation => engine
* priority: lowest => medium
* milestone: => 0.8.xx
* status_field: awaiting triage => in queue
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2837#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-13 00:26:30
|
#2742: look into using inline=true for bindparam() inside of DDL sequences
-----------------------------------+----------------------------------
Reporter: andreycizov | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | 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
* component: schema => postgres
* status_field: in queue => completed/closed
Comment:
two different issues:
1. need to render literals inline, not bound - I applied this individually
to the default compiler as well as to the compilers for postgresql, mssql,
mysql even though I'm not sure if expressions are valid for those other
two:
9bc9d5c1068be878118202259add3c master
d8c17e2a6f41d0aad331678e91 0.8
2. Postgresql requires parenthesis around any SQL expression that isn't a
straight
column inside the list of cols in CREATE INDEX
(http://www.postgresql.org/docs/9.1/static/sql-createindex.html)
a2cce1bf43552e699f2b master
70fdd3efa7a9a9a0fcf6ce 0.8
with these two changes your test case passes.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2742#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-11 23:16:23
|
#2837: Logging FAQ suggestion
----------------------------------+------------------------------------
Reporter: jonathan | Owner: zzzeek
Type: enhancement | Status: new
Priority: lowest | Milestone:
Component: documentation | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by jonathan):
Limiting the size of these fields logging is a much better idea.
It took me a while to dig out this general approach, and it seemed like a
natural "need" by the current system... and also not in-line with the
current docs. ( I did not expect the logger path to be different like
that, though it does make sense ).
My dev box uses SqlAlchemy as the message broker for Celery Resizing (it's
handled by Redis on Production ). All of the sudden during some tests,
I'm starting to see a 1.9MB jpeg converted into b64 and piped into an
INSERT statement on sqlalchemy. Not fun.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2837#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-11 22:58:04
|
#2837: Logging FAQ suggestion
----------------------------------+------------------------------------
Reporter: jonathan | Owner: zzzeek
Type: enhancement | Status: new
Priority: lowest | Milestone:
Component: documentation | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
though for FAQ, its OK sure. though logging should work better I think.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2837#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-10-11 22:57:46
|
#2837: Logging FAQ suggestion
----------------------------------+------------------------------------
Reporter: jonathan | Owner: zzzeek
Type: enhancement | Status: new
Priority: lowest | Milestone:
Component: documentation | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: awaiting triage |
----------------------------------+------------------------------------
Comment (by zzzeek):
why don't we fix logging not to log out the full expanse of long
binary/text fields ? we've already made similar enhancements long ago
regarding long parameter sets.
the doc suggestion is a little bit of a very specific recipe.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2837#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
186 messages has been excluded from this view by a project administrator.
