> session.merge only looks at the primary key of the instance you are
> inserting (it pays no attention to unique constraints). In your
> example, the table contains a single row with PK (1, 1), and you are
> merging an instance with PK (1, 4). SA sees these as different, so it
> tries to INSERT the new row.
>
> If (1, 4) is actually the new version of (1, 1), then I would say that
> your primary key should just be the acct_id column, not the pair of
> (acct_id, env_id). SA will then see them as the same row, and UPDATE
> rather than INSERT.
>
> Simon
>
While I agree with you philosophically, Simon, this utility is for an
off-the-shelf application, so I can't make changes to the underlying data
structure. I could, however, remove "env_id" as a primary key:
class CiAcctK(DeclarativeBase):
__tablename__ = 'ci_acct_k'
__table_args__ = {}
#column definitions
acct_id = Column(u'acct_id', CHAR(length=10),
ForeignKey('ci_acct.acct_id'), primary_key=True, unique=True,
nullable=False)
env_id = Column(u'env_id', NUMERIC(precision=6, scale=0),
primary_key=False, nullable=False)
Will this mapping cause any issues, given that the acct_id/env_id pair
really *is* the primary key?
Shawn
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sqlalchemy/-/cslGg8zn2QsJ.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
