| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
visit_NUMERIC see #2618
|
| | |
| |
| |
| |
| | |
so that they can be compared in ``__nonzero__`` prior to their
self_group() step. [ticket:2621]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some databases support this syntax for inserts:
INSERT INTO table (id, name) VALUES
('v1', 'v2'),
('v3', 'v4');
which greatly increases INSERT speed.
It is now possible to pass a list of lists/tuples/dictionaries as
the values param to the Insert construct. We convert it to a flat
dictionary so we can continue using bind params. The above query
will be converted to:
INSERT INTO table (id, name) VALUES
(:id, :name),
(:id0, :name0);
Currently only supported on postgresql, mysql and sqlite.
|
| | |
| |
| |
| | |
separate lists
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
:class:`.ColumnElement` would go into an endless loop, if
:meth:`.ColumnOperators.__getitem__` were implemented.
A new NotImplementedError is emitted via ``__iter__()``.
|
| |
|
|
|
|
|
|
| |
could be lost if the statement were used as a subquery
inside of another statement, as well as other similar
situations. Among other things, would cause
typing information to be lost when the Oracle/mssql dialects
would apply limit/offset wrappings. [ticket:2603]
|
| |
|
|
|
|
|
| |
used when producing a "proxy" of the column against
a selectable. This probably didn't occur in 0.7
since 0.7 doesn't respect the ".key" in a wider
range of scenarios. [ticket:2597]
|
| | |
|
| |
|
|
| |
- support annotations on Column where name isn't immediately present
|
| |
|
|
| |
- it appears we can get rid of all those "XYZ_toplevel" names and use :doc:.
|
| |
|
|
|
|
| |
- redefine inspect(Class.attrname).parent to be always an inspectable
target; either Mapper or AliasedInsp
- add most major features to 08 migration, document, link
|
| |
|
|
|
|
| |
:meth:`.ColumnOperators.notlike`,
:meth:`.ColumnOperators.notilike` to :class:`.ColumnOperators`.
[ticket:2580]
|
| |
|
|
|
|
|
|
| |
:meth:`.Compiler.process` wouldn't get propagated
to the column expressions present in the columns
clause of a SELECT statement. In particular this would
come up when used by custom compilation schemes that
relied upon special flags. [ticket:2593]
|
| |
|
|
|
|
|
|
|
| |
by proxy that of :class:`.orm.Query`, will not
take effect for a SELECT statement that is being
rendered directly in the FROM list of the enclosing
SELECT. Correlation in SQL only applies to column
expressions such as those in the WHERE, ORDER BY,
columns clause. [ticket:2595]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"tuple" rows that contain
types which aren't hashable, by setting the flag
"hashable=False" on the corresponding TypeEngine object
in use. Custom types that return unhashable types
(typically lists) can set this flag to False.
[ticket:2592]
- [bug] Applying a column expression to a select
statement using a label with or without other
modifying constructs will no longer "target" that
expression to the underlying Column; this affects
ORM operations that rely upon Column targeting
in order to retrieve results. That is, a query
like query(User.id, User.id.label('foo')) will now
track the value of each "User.id" expression separately
instead of munging them together. It is not expected
that any users will be impacted by this; however,
a usage that uses select() in conjunction with
query.from_statement() and attempts to load fully
composed ORM entities may not function as expected
if the select() named Column objects with arbitrary
.label() names, as these will no longer target to
the Column objects mapped by that entity.
[ticket:2591]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to help with generative building. Also slight adjustment
regarding how SS "correlates" columns; the new methodology
no longer applies meaning to the underlying
Table column being selected. This improves
some fairly esoteric situations, and the logic
that was there didn't seem to have any purpose.
- [feature] Some support for auto-rendering of a
relationship join condition based on the mapped
attribute, with usage of core SQL constructs.
E.g. select([SomeClass]).where(SomeClass.somerelationship)
would render SELECT from "someclass" and use the
primaryjoin of "somerelationship" as the WHERE
clause. This changes the previous meaning
of "SomeClass.somerelationship" when used in a
core SQL context; previously, it would "resolve"
to the parent selectable, which wasn't generally
useful. Related to [ticket:2245].
|
| |
|
|
|
|
|
|
|
|
|
| |
String types. When present, renders as
COLLATE <collation>. This to support the
COLLATE keyword now supported by several
databases including MySQL, SQLite, and Postgresql.
[ticket:2276]
- [change] The Text() type renders the length
given to it, if a length was specified.
|
| |
|
|
|
|
|
| |
API to better support highly specialized
systems such as the Akiban database, including
more hooks to allow an execution context to
access type processors.
|
| |
|
|
|
|
|
| |
- rewrite --dropfirst to be more industrial strength, includes views
- fix order_by="foreign_key" to maintain the same ordering as
metadata.sorted_tables. Not ideal that this was the other way throughout
0.7 but this is still a little-used method, in contrast to metadata.sorted_tables.
|
| | |
|
| |
|
|
|
|
|
|
| |
passing an empty list for either partition_by
or order_by, as opposed to None, would fail
to generate correctly.
Courtesy Gunnlaugur Por Briem.
[ticket:2574]
|
| |
|
|
|
|
|
|
| |
will now schema-qualify the name of the index
to be that of the parent table. Previously this
name was omitted which apparently creates the
index in the default schema, rather than that
of the table.
|
| |
|
|
|
| |
an Index associated with a Table in a remote
schema. [ticket:2571]
|
| |
|
|
|
|
| |
__dict__.pop(),
remove reset_memoized
|
| |
|
|
|
|
|
| |
"concat" and "match" operators to be the same as
that of "is", "like", and others; this helps with
parenthesization rendering when used in conjunction
with "IS". [ticket:2564]
|
| | |
|
| |
|
|
|
|
| |
to the ColumnOperators base, so that these long-available
operators are present as methods like all
the other operators. [ticket:2544]
|
| |
|
|
|
| |
no length is attempted to be emitted, same
way as MySQL. [ticket:2505]
|
| |
|
|
|
|
|
|
|
| |
will now be produced via the func.* accessor
as well, as users naturally try to access these
names from func.* they might as well do
what's expected, even though the returned
object is not a FunctionElement.
[ticket:2562]
|
| |
|
|
|
|
|
| |
CREATE TABLE that provides access to the render for each
Column individually, by constructing a @compiles
function against the new schema.CreateColumn
construct. [ticket:2463]
|
| | |
|
| |
|
|
|
|
| |
delivered to a result set. therefore these expressions should only be rendered
for those columns that are being delivered to the result, thereby preventing
the expression from stacking onto itself within nesting scenarios.
|
| |
|
|
|
|
| |
select.apply_labels(),
label should be the column name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
result-row targeting. It should be possible
to use a select() statement with string
based columns in it, that is
select(['id', 'name']).select_from('mytable'),
and have this statement be targetable by
Column objects with those names; this is the
mechanism by which
query(MyClass).from_statement(some_statement)
works. At some point the specific case of
using select(['id']), which is equivalent to
select([literal_column('id')]), stopped working
here, so this has been re-instated and of
course tested. [ticket:2558]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
contains() operators to do a better job with
negation (NOT LIKE), and also to assemble them
at compilation time so that their rendered SQL
can be altered, such as in the case for Firebird
STARTING WITH [ticket:2470]
- [feature] firebird - The "startswith()" operator renders
as "STARTING WITH", "~startswith()" renders
as "NOT STARTING WITH", using FB's more efficient
operator. [ticket:2470]
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
True by default, if not passed explicitly,
on bindparam() if the "value" or "callable"
parameters are not passed.
This will cause statement execution to check
for the parameter being present in the final
collection of bound parameters, rather than
implicitly assigning None. [ticket:2556]
|
| |
|
|
| |
"identifier" in func.
|
| |
|
|
|
| |
arguments is easier to understand
- add a test to ensure generic function can have a custom name
|
| |
|
|
|
|
| |
and might have issues with
pks, multiple function calls
|
| | |
|
| | |
|
| |
|
|
| |
[ticket:2461]
|
| |
|
|
|
|
|
|
| |
or similar inside of an embedded subquery
would interfere with result-column targeting,
in the case that a result-column had the same
ultimate name as a name inside the embedded
UNION. [ticket:2552]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"ambiguous column error" would fail to
function properly if the given index were
a Column object and not a string.
Note there are still some column-targeting
issues here which are fixed in 0.8.
[ticket:2553]
- find more cases where column targeting is being inaccurate, add
more information to result_map to better differentiate "ambiguous"
results from "present" or "not present". In particular, result_map
is sensitive to dupes, even though no error is raised; the conflicting
columns are added to the "obj" member of the tuple so that the two
are both directly accessible in the result proxy
- handwringing over the damn "name fallback" thing in results. can't
really make it perfect yet
- fix up oracle returning clause. not sure why its guarding against
labels, remove that for now and see what the bot says.
|
| |
|
|
|
|
|
| |
to allow for user-defined GenericFunction
subclasses to be available via the func.*
namespace automatically by classname,
optionally using a package name as well.
|
| |
|
|
| |
column to Table column
|
