[Sqlalchemy-commits] commit/sqlalchemy: zzzeek: - new approach to autoincrement, towards references #3216

[Bitbucket <com...@bi...>]

1 new commit in sqlalchemy:

https://bitbucket.org/zzzeek/sqlalchemy/commits/8f81f07917a7/
Changeset:   8f81f07917a7
Branch:      ticket_3216
User:        zzzeek
Date:        2015-08-21 19:35:00+00:00
Summary:     - new approach to autoincrement, towards references #3216
- We add a new value of "autoincrement" called "auto".  This is now the
default for all columns, no longer True.
- the work of determining _autoincrement_column now moves to
PrimaryKeyConstraint itself, as "autoincrement" is explictly a pk-only
concept
- pkc detects autoincrement at the same time Table did, based on memoized_property.
attempts to make this a more "active" setting are more complicated because
during table construction with or without reflection the columns within the
pkc are in flux and determiniations can't really be made without
looking at all columns.
- with the difference between "auto" and True, we now can add validation
rules when True is set:  1. only one column may have autoincrement=True
2. autoincrement=True *requires* an Integer type, error is raised otherwise
3. column default has to be None or a Sequence 4. column server_default has
to be None or server-reflected
- when autoincrement=True is not set, we're looking for autoincrement='auto'.
We only care about 'auto' when there is *only one column in the PK*.  E.g.
we no longer set *any* column to "autoincrement" implicitly if the key
is composite, this requires "autoincrement=True".  This is the core of
- we get rid of the awkward rule that we create "KEY idx_autoinc_foo"
for a MySQL InnoDB column that is explicit autoincrement in a composite
PK and not the first column.  that was a terrible idea.  when the
non-first column in a composite PK is autoincrement=True, *we render it
first in the PRIMARY KEY constraint*.  Problem solved, no more implicit
index, no more guessing if we're innodb (this guess was wrong in the case
of innodb set on the server anyway).  this is again a proposal for a big
change in behavior; positives include that a surprise KEY is no longer
created, won't show up in alembic autogen and generates a more
efficient structure.
- databases where "autoincrement" is entirely implicit, e.g. SQLite,
should raise an error now when autoincrement=True is set and can't
be satisfied; SQLite dialect now raises this if autoincrement=True
on a composite primary key since SQLite never does this (note
that as always, this is distinct from SQLite's "sqlite_autoincrement"
keyword which we support distinctly).

Affected #:  7 files

Repository URL: https://bitbucket.org/zzzeek/sqlalchemy/

--

This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.