sqlalchemy-tickets Mailing List for SQLAlchemy (Page 89)
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-06-26 17:49:33
|
#2763: retaining=True flag on firebird dialects should be configurable
------------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: firebird | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Changes (by zzzeek):
* priority: high => highest
* status_field: needs questions answered => in progress
Comment:
just add the flag for now and default it to true, verbiage will be vague
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2763#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 17:39:19
|
#2746: allow correlation of FROM elements to any SELECT which encloses via WHERE,
columns, ORDER BY (but not FROM list)
-----------------------------------+---------------------------------------
Reporter: sayap | Owner: zzzeek
Type: defect | Status: closed
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: very major - up to 2 days
Resolution: fixed | Keywords:
Progress State: completed/closed |
-----------------------------------+---------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => fixed
* severity: minor - half an hour => very major - up to 2 days
* status_field: in progress => completed/closed
Comment:
rf76cae4bc92da640c1 master
rb4697e9e187571b06 0.8
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:11>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 15:46:57
|
#2767: Reflection of indexes in PostgreSQL doesn't preserve the order of columns
-----------------------------------+----------------------------------
Reporter: malor | Owner: zzzeek
Type: defect | Status: closed
Priority: medium | Milestone: 0.8.xx
Component: postgres | Severity: minor - half an hour
Resolution: fixed | Keywords: reflection,indexes
Progress State: completed/closed |
-----------------------------------+----------------------------------
Changes (by zzzeek):
* status: new => closed
* milestone: => 0.8.xx
* resolution: => fixed
* status_field: needs review => completed/closed
Comment:
master:
0333ee23d3fb88ed032ff61 ef6245a3caa10b0d1e1a
0.8:
59c01813adf01c75d fee954f2534eba6 699fdd4330879
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2767#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 15:20:41
|
#2746: allow correlation of FROM elements to any SELECT which encloses via WHERE,
columns, ORDER BY (but not FROM list)
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Comment (by zzzeek):
I'm going to try taking it one step further, and make it so that if you
dont actually use correlate()/correlate_except(), the default auto-
correlation will work the old way, i.e. just for the immediate enclosing
SELECT via WHERE/etc. This is to minimize the chance of someone's query
behaving differently since I want this in 0.8 - it will act very close to
the 0.7 behavior.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:10>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 14:10:22
|
#2746: allow correlation of FROM elements to any SELECT which encloses via WHERE,
columns, ORDER BY (but not FROM list)
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Comment (by sayap):
Just tested 1b6b2fb8d2ea and everything just works indeed. Nice.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:9>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 06:11:22
|
#2746: allow correlation of FROM elements to any SELECT which encloses via WHERE,
columns, ORDER BY (but not FROM list)
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Comment (by zzzeek):
good news. We don't need a flag. the latest patch has the compiler
figure out what the legal "correlations" should be, so all these scenarios
just work.
this is a pretty big change but 0.8's current behavior is pretty broken.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-26 05:27:18
|
#2767: Reflection of indexes in PostgreSQL doesn't preserve the order of columns
--------------------------------+---------------------------------------
Reporter: malor | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: postgres | Severity: minor - half an hour
Keywords: reflection,indexes | Progress State: needs review
--------------------------------+---------------------------------------
Reflection of indexes in PostgreSQL returns columns in different order
comparing to the one of original index. As order of columns in index
definition does matter, this must be fixed.
Code to reproduce the bug:
{{{
import sqlalchemy as sa
eng = sa.create_engine('postgresql://test:test@localhost/test')
meta = sa.MetaData(bind=eng)
meta2 = sa.MetaData(bind=eng)
table = sa.Table(
'testtbl', meta,
sa.Column('a', sa.Integer),
sa.Column('b', sa.Integer),
sa.Column('c', sa.Integer),
sa.Index('test_idx', 'b', 'a', 'c')
)
meta.create_all()
table2 = sa.Table('testtbl', meta2, autoload=True)
idx = table2.indexes.pop()
assert idx.columns.keys() == ['b', 'a', 'c']
}}}
I'll provide the fix soon via pull request on GitHub
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2767>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 22:07:28
|
#2746: Add a flag to explicitly enable correlation even when the subquery has
`asfrom=True`
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: defect | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Changes (by zzzeek):
* type: enhancement => defect
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 22:07:20
|
#2746: Add a flag to explicitly enable correlation even when the subquery has
`asfrom=True`
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: enhancement | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in progress |
------------------------------+----------------------------------
Changes (by zzzeek):
* status_field: needs tests => in progress
Comment:
this is in the ticket_2746 branch for now and also in the attached patch.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 21:24:21
|
#2746: Add a flag to explicitly enable correlation even when the subquery has
`asfrom=True`
------------------------------+----------------------------------
Reporter: sayap | Owner: zzzeek
Type: enhancement | Status: new
Priority: highest | Milestone: 0.8.xx
Component: sql | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: needs tests |
------------------------------+----------------------------------
Comment (by zzzeek):
from that change we also can fix correlate_except, which also doesn't do
the right thing here:
{{{
#!python
from sqlalchemy.sql import table, column, select, exists
t1 = table('t1', column('x'))
t2 = table('t2', column('y'))
t3 = table('t3', column('z'))
s = select([t1]).where(t1.c.x == t2.c.y).where(t2.c.y ==
t3.c.z).correlate_except(t1)
print s
}}}
we want:
{{{
SELECT t1.x
FROM t1, t2, t3
WHERE t1.x = t2.y AND t2.y = t3.z
}}}
and not
{{{
SELECT t1.x
FROM t1
WHERE t1.x = t2.y AND t2.y = t3.z
}}}
a similar pattern to the latter is called "backwards correlated" in
test_compiler...but its wrong, and I'd like to be able to add other FROM
clauses to an `any()` or `has()`.
This is getting pretty changy. I don't think there's a real-world use for
"backwards correlated" and correlate_except() is fairly new so hopefully
this is safe for 0.8 still.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2746#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 18:49:26
|
#2766: backslashes in HSTORE
---------------------------+----------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: postgres | Severity: minor - half an hour
Resolution: | Keywords:
Progress State: in queue |
---------------------------+----------------------------------
Comment (by zzzeek):
I'd like to add some actual round trip tests here since I'd like to see
what postgresql is expecting, and also understand at what point psycopg2
is doing the serialization, not us, and same problems there or not ?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2766#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 18:45:48
|
#2766: backslashes in HSTORE
----------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.8.xx
Component: postgres | Severity: minor - half an hour
Keywords: | Progress State: in queue
----------------------+---------------------------------------
patch attached
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2766>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-25 06:59:29
|
#2765: Cascading with "delete-orphan" will insert new children, before deleting
removed children, causing unique constraint violations
-------------------------+-------------------------------------------------
Reporter: | Owner: zzzeek
logandk | Status: closed
Type: defect | Milestone:
Priority: medium | Severity: no triage selected yet
Component: orm | Keywords: orm,delete,orphan,unique,constraint
Resolution: |
duplicate |
Progress State: |
completed/closed |
-------------------------+-------------------------------------------------
Comment (by logandk):
Sorry about the duplicate report, I didn't find the other ticket by
search. Thanks for looking into it, I see now that it is a more
complicated issue.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2765#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 19:04:35
|
#2501: the DELETE before INSERT problem
------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.0
Component: orm | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: needs tests |
------------------------------+---------------------------------------
Comment (by zzzeek):
that example earlier with the Parent.children, yeah that kind of thing
still might not work. but I don't think that's what folks are going for
with this one in most cases.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:9>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 19:02:01
|
#2501: the DELETE before INSERT problem
------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.0
Component: orm | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: needs tests |
------------------------------+---------------------------------------
Changes (by zzzeek):
* status_field: in progress => needs tests
Comment:
so it's ready for tests, and also probably needs some work regarding
inheritance.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 18:59:49
|
#2501: the DELETE before INSERT problem
------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.0
Component: orm | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: in progress |
------------------------------+---------------------------------------
Comment (by zzzeek):
also test an update (new patch coming):
{{{
#!python
# test with an update
c4 = sess.query(ChildEntity).filter_by(z=4.0).one()
c5 = sess.query(ChildEntity).filter_by(z=5.5).one()
c4.z = 5.5
sess.delete(c5)
sess.commit()
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 18:26:43
|
#2765: Cascading with "delete-orphan" will insert new children, before deleting
removed children, causing unique constraint violations
-------------------------+-------------------------------------------------
Reporter: | Owner: zzzeek
logandk | Status: closed
Type: defect | Milestone:
Priority: medium | Severity: no triage selected yet
Component: orm | Keywords: orm,delete,orphan,unique,constraint
Resolution: |
duplicate |
Progress State: |
completed/closed |
-------------------------+-------------------------------------------------
Comment (by zzzeek):
yeah and a patch. It uses a new setting, which if not used means there's
no change to current behavior. Will see if it can go in for 0.9.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2765#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 18:24:59
|
#2501: the DELETE before INSERT problem
------------------------------+---------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.0
Component: orm | Severity: very major - up to 2 days
Resolution: | Keywords:
Progress State: in progress |
------------------------------+---------------------------------------
Changes (by zzzeek):
* priority: medium => high
* milestone: blue sky => 0.9.0
* severity: refactor - over two days => very major - up to 2 days
* status_field: not decided upon => in progress
Comment:
fine, a patch is attached. it would be safe to release since it takes no
effect unless a new mapper setting "maintain_unique_attributes" is used.
As far as what breaks when one uses this attribute, hard to say, though i
think mostly the breakage would be when the mapper has lots of other
things dependent on it.
Usage so far requires that one can detect a "dupe" before the UOW assigns
foreign keys. So in the example like we got in #2765, it has to check for
uniques on the relationship-bound attribute where the change has occurred.
but you can also give it several pairs of things to check.
{{{
#!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 sessionmaker, 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)
class ChildEntity(Base):
__tablename__ = 'child'
__table_args__ = (UniqueConstraint('parent_id', 'z',
name='child_uk'),)
__mapper_args__ = {
"maintain_unique_attributes": [("parent", "z")]
# to detect conflicts for both relationship as well as on the
integer
# attribute
# "maintain_unique_attributes": [("parent", "z"), ("parent_id",
"z")]
}
id = Column(Integer, primary_key=True)
parent_id = Column(Integer, ForeignKey('parent.id'), nullable=False)
z = Column(Float)
parent = relationship("ParentEntity",
backref=backref("children",
cascade="all, delete-orphan"))
engine = create_engine('sqlite://', echo=True)
Session = sessionmaker(bind=engine)
sess = Session()
Base.metadata.create_all(engine)
p = ParentEntity(name='Datum')
p.children = [ChildEntity(z=2.5), ChildEntity(z=3.5), ChildEntity(z=5.5)]
sess.add(p)
sess.commit()
# Remove all existing children and create new, one of which is
# identical to a previously existing child
p.children = [ChildEntity(z=4.0), ChildEntity(z=5.5)]
sess.commit()
c5 = sess.query(ChildEntity).filter_by(z=5.5).one()
sess.delete(c5)
sess.add_all([
ChildEntity(z=5.5, parent=p)
])
sess.commit()
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 17:27:02
|
#2765: Cascading with "delete-orphan" will insert new children, before deleting
removed children, causing unique constraint violations
-------------------------+-------------------------------------------------
Reporter: | Owner: zzzeek
logandk | Status: closed
Type: defect | Milestone:
Priority: medium | Severity: no triage selected yet
Component: orm | Keywords: orm,delete,orphan,unique,constraint
Resolution: |
duplicate |
Progress State: |
completed/closed |
-------------------------+-------------------------------------------------
Comment (by zzzeek):
a new proof of concept illustrating the basic idea for UOW changes has
been attached to #2501. It takes stock of the basic mechanics we'd have
to use in order to achieve this.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2765#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 17:25:35
|
#2501: the DELETE before INSERT problem
-----------------------------------+--------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone: blue sky
Component: orm | Severity: refactor - over two days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+--------------------------------------
Comment (by zzzeek):
a proof of concept is attached illustrating how to get #2765's test to
work. Encouragingly, we can get an external rule to do the whole thing
(in this simple case at least) without any code changes.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 14:29:34
|
#2501: the DELETE before INSERT problem
-----------------------------------+--------------------------------------
Reporter: zzzeek | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone: blue sky
Component: orm | Severity: refactor - over two days
Resolution: | Keywords:
Progress State: not decided upon |
-----------------------------------+--------------------------------------
Comment (by zzzeek):
#2765 related.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2501#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 14:29:23
|
#2765: Cascading with "delete-orphan" will insert new children, before deleting
removed children, causing unique constraint violations
-------------------------+-------------------------------------------------
Reporter: | Owner: zzzeek
logandk | Status: closed
Type: defect | Milestone:
Priority: medium | Severity: no triage selected yet
Component: orm | Keywords: orm,delete,orphan,unique,constraint
Resolution: |
duplicate |
Progress State: |
completed/closed |
-------------------------+-------------------------------------------------
Changes (by zzzeek):
* status: new => closed
* resolution: => duplicate
* status_field: awaiting triage => completed/closed
Comment:
this is #2501, there's no fix on the horizon. You'll need to emit a
flush() in between for the time being.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2765#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 11:25:34
|
#2765: Cascading with "delete-orphan" will insert new children, before deleting
removed children, causing unique constraint violations
-------------------------------------+-------------------------------------
Reporter: logandk | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone:
Component: orm | Severity: no triage selected
Keywords: | yet
orm,delete,orphan,unique,constraint| Progress State: awaiting triage
-------------------------------------+-------------------------------------
This issue occurs under the following circumstances:
* When a relationship has the cascade property set to "all, delete-
orphan",
* There is a UniqueConstraint set on the child model
* Simultaneously deleting and creating new child objects, through the
backref on the parent, that have common values in the unique fields
I believe this is a bug, and that it can be fixed by first deleting the
removed children, followed by insertion of new children.
The following example recreates the issue on SQLAlchemy 0.8.1.
{{{
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 sessionmaker, 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)
class ChildEntity(Base):
__tablename__ = 'child'
__table_args__ = (UniqueConstraint('parent_id', 'z',
name='child_uk'),)
id = Column(Integer, primary_key=True)
parent_id = Column(Integer, ForeignKey('parent.id'), nullable=False)
z = Column(Float)
parent = relationship("ParentEntity",
backref=backref("children",
cascade="all, delete-orphan"))
engine = create_engine('sqlite://', echo=True)
Session = sessionmaker(bind=engine)
sess = Session()
Base.metadata.create_all(engine)
p = ParentEntity(name='Datum')
p.children = [ChildEntity(z=2.5), ChildEntity(z=3.5), ChildEntity(z=5.5)]
sess.add(p)
sess.commit()
# Remove all existing children and create new, one of which is identical
to a previously existing child
p.children = [ChildEntity(z=4.0), ChildEntity(z=5.5)]
sess.commit()
}}}
Running this example produces the following error:
{{{
sqlalchemy.exc.IntegrityError: (IntegrityError) columns parent_id, z are
not unique u'INSERT INTO child (parent_id, z) VALUES (?, ?)' (1, 5.5)
}}}
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2765>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 04:57:42
|
#2764: Make sqlite handle BIGINT
------------------------------+------------------------------------
Reporter: rstuart4133 | Owner: zzzeek
Type: enhancement | Status: new
Priority: low | Milestone: 0.8.xx
Component: sqlite | Severity: no triage selected yet
Resolution: | Keywords:
Progress State: in queue |
------------------------------+------------------------------------
Changes (by zzzeek):
* status_field: awaiting triage => in queue
* milestone: => 0.8.xx
Comment:
minor bugfix patches are going into 0.8 at this point.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2764#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
|
From: sqlalchemy <mi...@zz...> - 2013-06-24 04:31:42
|
#2764: Make sqlite handle BIGINT
-------------------------+-----------------------------------------
Reporter: rstuart4133 | Owner: zzzeek
Type: enhancement | Status: new
Priority: low | Milestone:
Component: sqlite | Severity: no triage selected yet
Keywords: | Progress State: awaiting triage
-------------------------+-----------------------------------------
Consider this example:
{{{
Python 2.7.3 (default, Jan 2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Debug helper loaded. Type "print(D.__doc__)" for help.
>>> import sqlalchemy as s
>>> c = s.create_engine("sqlite:///:memory:")
>>> c = s.create_engine("sqlite:///:memory:").connect()
>>> m = s.MetaData(bind=c)
>>> x = s.Table("x", m, s.Column("x", s.types.BIGINT, nullable=False))
>>> x.create()
>>> m1 = s.MetaData(bind=c)
>>> xx = s.Table('x', m1, autoload=True)
/usr/lib/python2.7/dist-packages/sqlalchemy/engine/reflection.py:47:
SAWarning: Did not recognize type 'BIGINT' of column 'x'
ret = fn(self, con, *args, **kw)
>>>
}}}
Sqlalchemy should be able to parse the metadata of tables it creates. The
warning message demonstrates it can't for BIGINT's. The attached patch
fixes it.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2764>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|
186 messages has been excluded from this view by a project administrator.
