- update "not supported" messages for empty inserts, mutlivalue inserts
- rework the ValuesBase approach for multiple value sets so that stmt.parameters
does store a list for multiple values; the _has_multiple_parameters flag now indicates
which of the two modes the statement is within. it now raises exceptions if a subsequent
call to values() attempts to call a ValuesBase with one mode in the style of the other
mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode,
and also if a multiple value is passed simultaneously with a kwargs set.
Added tests for these error conditions
- Calling values() multiple times in multivalue mode now extends the parameter list to
include the new parameter sets.
- add error/test if multiple *args were passed to ValuesBase.values()
- rework the compiler approach for multivalue inserts, back to where
_get_colparams() returns the same list of (column, value) as before, thereby
maintaining the identical number of append() and other calls when multivalue
is not enabled. In the case of multivalue, it makes a last-minute switch to return
a list of lists instead of the single list. As it constructs the additional lists, the inline
defaults and other calculated default parameters of the first parameter
set are copied into the newly generated lists so that these features continue
to function for a multivalue insert. Multivalue inserts now add no additional
function calls to the compilation for regular insert constructs.
- parameter lists for multivalue inserts now includes an integer index for all
parameter sets.
- add detailed documentation for ValuesBase.values(), including careful wording
to describe the difference between multiple values and an executemany() call.
- add a test for multivalue insert + returning - it works !
- remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
:class:`.ColumnElement` would go into an endless loop, if
:meth:`.ColumnOperators.__getitem__` were implemented.
A new NotImplementedError is emitted via ``__iter__()``.
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
are now returned in the order in which the constraint
itself defines them, rather than how the table
orders them. Courtesy Gunnlaugur Por Briem.
[ticket:2531].
more lenient as to the table
being updated. Plain Table objects are better
supported now, and additional a joined-inheritance
subclass may be used with update(); the subclass
table will be the target of the update,
and if the parent table is referenced in the
WHERE clause, the compiler will call upon
UPDATE..FROM syntax as allowed by the dialect
to satisfy the WHERE clause. Target columns
must still be in the target table i.e.
does not support MySQL's multi-table update
feature (even though this is in Core).
PG's DELETE..USING is also not available
in Core yet.
the `getitem` operator, i.e. the bracket
operator in Python. This is used at first
to provide index and slice behavior to the
Postgresql ARRAY type, and also provides a hook
for end-user definition of custom __getitem__
schemes which can be applied at the type
level as well as within ORM-level custom
operator schemes.
Note that this change has the effect that
descriptor-based __getitem__ schemes used by
the ORM in conjunction with synonym() or other
"descriptor-wrapped" schemes will need
to start using a custom comparator in order
to maintain this behavior.
- [feature] postgresql.ARRAY now supports
indexing and slicing. The Python [] operator
is available on all SQL expressions that are
of type ARRAY; integer or simple slices can be
passed. The slices can also be used on the
assignment side in the SET clause of an UPDATE
statement by passing them into Update.values();
see the docs for examples.
- [feature] Added new "array literal" construct
postgresql.array(). Basically a "tuple" that
renders as ARRAY[1,2,3].
ForeignKeyConstraint, courtesy Ryan Kelly.
[ticket:2502]
- [feature] Added support for DELETE and UPDATE from
an alias of a table, which would assumedly
be related to itself elsewhere in the query,
courtesy Ryan Kelly. [ticket:2507]
- [feature] Added support for the Postgresql ONLY
keyword, which can appear corresponding to a
table in a SELECT, UPDATE, or DELETE statement.
The phrase is established using with_hint().
Courtesy Ryan Kelly [ticket:2506]
"dimension" argument, will assign a specific
number of dimensions to the array which will
render in DDL as ARRAY[][]..., also improves
performance of bind/result processing.
[ticket:2441]
CompileException for all type/statement compilation
issues, instead of InvalidRequestError or ArgumentError.
The DDL for CREATE TABLE will re-raise
CompileExceptions to include table/column information
for the problematic column. [ticket:2361]
to pg.ENUM. When False, no CREATE/DROP or
checking for the type will be performed as part
of a table create/drop event; only the
create()/drop)() methods called directly
will do this. Helps with Alembic "offline"
scripts.
particular name was processed
during a create/drop sequence. This allows
a create/drop sequence to work without any
calls to "checkfirst", and also means with
"checkfirst" turned on it only needs to
check for the ENUM once. [ticket:2311]
a foreign-key referenced table with schema in
the current search path; an explicit schema will
be applied to the referenced table only if
it actually matches that of the referencing table,
which also has an explicit schema. Previously
it was assumed that "current" schema was synonymous
with the full search_path. [ticket:2249]
MATCH operator. A potential floating-point
inaccuracy issue was fixed, and certain tests
of the MATCH operator only execute within an
EN-oriented locale for now. [ticket:2175].
Also in 0.6.8.
by Postgresql, SQL Server, MySQL, SQLite. Note
that the SQL Server and MySQL versions, which
add extra arguments, are also still available
from those dialects. [ticket:2081]
access to the cls/self.tables/classes registries
- express orm/_base.py ORMTest in terms of engine/_base.py TablesTest,
factor out common steps into TablesTest, remove AltEngineTest as a
separate class. will further consolidate these base classes
Audrius Kažukauskas