| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in result sets is now case sensitive by
default. SQLAlchemy for many years would
run a case-insensitive conversion on these values,
probably to alleviate early case sensitivity
issues with dialects like Oracle and
Firebird. These issues have been more cleanly
solved in more modern versions so the performance
hit of calling lower() on identifiers is removed.
The case insensitive comparisons can be re-enabled
by setting "case_insensitive=False" on
create_engine(). [ticket:2423]
|
| |
|
|
|
|
|
|
|
| |
emitted after the object is established
in Session.new or Session.identity_map
upon Session.add(), Session.merge(),
etc., so that the object is represented
in these collections when the event
is called. [ticket:2464]
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
have been overhauled to support a more open
ended format for input and output, using
name based format strings and regexps. A
new argument "microseconds" also provides
the option to omit the "microseconds"
portion of timestamps. Thanks to
Nathan Wright for the work and tests on
this. [ticket:2363]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This breaks backwards compatibility with old SQLite DATETIME, DATE,
and TIME storage_format strings. Formatting now occurs with named instead
of positional parameters. The regexp argument can still use positional
arguments, but named groupings are also supported. This means that you can
omit fields and change the order of date fields as desired.
SQLite's DATETIME and TIME also gained a truncate_microseconds argument.
This is shorthand for modifying the format string. Fortunately the
str_to_datetime and str_to_time processors written in C already support
omitting microseconds, so we don't have to resort to python processing
for this case.
|
| | |
| |
| |
| | |
- remove sqlalchemy.exceptions [ticket:2433]
|
| | |
| |
| |
| |
| |
| | |
anonymous label, instead of returning the
column object itself, consistent with the behavior
of label(column, None). [ticket:2168]
|
| | |
| |
| |
| |
| |
| |
| | |
for registration of new dialects in-process
without using an entrypoint. See the
docs for "Registering New Dialects".
[ticket:2462]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
accepts the Inspector object as the first
argument, preceding "table". Code which
uses the 0.7 version of this very new
event will need modification to add the
"inspector" object as the first argument.
[ticket:2418]
|
| | |
| |
| |
| |
| |
| |
| |
| | |
delete-orphan cascade with one-to-many
or many-to-many without single-parent=True
is now an error. The ORM
would fail to function subsequent to this
warning in any case. [ticket:2405]
|
| | |
| |
| |
| |
| |
| |
| |
| | |
no longer has any effect. is_modified() in
all cases looks only at local in-memory
modified flags and will not emit any
SQL or invoke loader callables/initializers.
[ticket:2320]
|
| | |
| |
| |
| |
| |
| |
| |
| | |
.c. attribute of a select().apply_labels()
is now based on <tablename>_<colkey> instead
of <tablename>_<colname>, for those columns
that have a distinctly named .key.
[ticket:2397]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
a column comparison to a scalar SELECT via
== would coerce to an IN with the SQL server
dialect. This is implicit
behavior which fails in other scenarios
so is removed. Code which relies on this
needs to be modified to use column.in_(select)
explicitly. [ticket:2277]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
provides the functionality of query.with_polymorphic()
in a standalone form. It can be applied to any
entity within a query, including as the target
of a join in place of the "of_type()" modifier.
[ticket:2333]
- redo a large portion of the inheritance docs in terms
of declarative, new with_polymorphic() function
- upgrade examples/inheritance/polymorph, rename to "joined"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ORM, including the MutableType class as well
as the mutable=True flag on PickleType
and postgresql.ARRAY has been removed.
In-place mutations are detected by the ORM
using the sqlalchemy.ext.mutable extension,
introduced in 0.7. The removal of MutableType
and associated constructs removes a great
deal of complexity from SQLAlchemy's internals.
The approach performed poorly as it would incur
a scan of the full contents of the Session
when in use. [ticket:2442]
|
| | |
| |
| |
| | |
overhead to it now
|
| | |
| |
| |
| | |
- callcount here seems to have gone up by five, reason not certain
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
- start dressing up InstanceState for it's coming out, start moving
internal things to be underscored within the lib
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- resolved some serious speed hits I missed, we need to ensure
only deannotated columns are used in the local/remote collections and soforth
so that hash lookups against mapped columns don't dig into __eq__()
- fix some other parity mismatches regarding stuff from [ticket:2453],
including finding another case where _deep_annotate() was doing the wrong thing,
new tests.
- [feature] Major rewrite of relationship()
internals now allow join conditions which
include columns pointing to themselves
within composite foreign keys. A new
API for very specialized primaryjoin conditions
is added, allowing conditions based on
SQL functions, CAST, etc. to be handled
by placing the annotation functions
remote() and foreign() inline within the
expression when necessary. Previous recipes
using the semi-private _local_remote_pairs
approach can be upgraded to this new
approach. [ticket:1401]
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
- add foreign, remote annotations to declarative
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
if otherwise can't determine join condition due to no fks
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- got everything working. just need to update
error strings
|
| | | | | |
| | | | |
| | | | |
| | | | | |
tests still failing
|
| | | | | |
| | | | |
| | | | |
| | | | | |
test_eager_relations:CorrelatedSubqueryTest but need some more testing here
|
| | | | | |
| | | | |
| | | | |
| | | | | |
- fix up subquery eager loading
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- using new traversal that returns the product of both sides
of a binary, starting to work with (a+b) == (c+d) types of joins.
primaryjoins on functions working
- annotations working, including reversing local/remote when
doing backref
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
annotation.
also added in sync pairs, etc. many-to-many is currently broken.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
assumed
|
| | | | | |
| | | | |
| | | | |
| | | | | |
catch the actual remote columns more accurately.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
100%
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
everything known about the relationship in an ORM-agnostic
way. The primaryjoin is determined as before, but is
then immediately parsed and annotated with "foreign",
"local" and "remote" annotations. These annotations
will then drive the additional decisions made, namely
"direction" and "sync pairs". The end user will be
able to pass a pre-annotated join condition in which
case those annotations take effect as given, which
will in one pass fix both #1401 as well as #610
(for #610, the "foreign" / "remote" annotation can
recursively descend down to ColumnElement objects).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
additional tests in #1401 pass.
would now like to reorganize RelationshipProperty more around the annotations concept.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[ticket:2409] whereby column_mapped_collection
used against columns that were mapped as
joins or other indirect selectables
would fail to function.
Here, the serialize use case has gotten very complex since to
really target a column we'd need the root MetaData object,
then if we're hitting Alias objects and such there's really
nothing to hold onto. Short of building a system where
Column objects have some kind of master hash identifier that
is consistently generated, the way this works can't really
suit every case - much easier would be to change the mechanics
of collections.py to make available the Mapper to the
collection adapter when it's first invoked.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
requires that the updated table be present
in the FROM clause when an alias of that
table is also present in the FROM clause.
The updated table is now always present
in the FROM, when FROM is present
in the first place. Courtesy sayap.
[ticket:2468]
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
on a SQL expression whose type is not supported
by cast() and therefore CAST isn't rendered by
the dialect, the order of evaluation could change
if the casted expression required that it be
grouped; grouping is now applied to those
expressions. [ticket:2467]
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
"with engine.begin()", the newly acquired
Connection is closed explicitly before
propagating the exception onward normally.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
- move the test to the reflection tests
|
| | | | | |
| | | | |
| | | | |
| | | | | |
those in information_schema
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
include_removes. When True, collection
remove and attribute del events
will also be sent to the validation function,
which accepts an additional argument
"is_remove" when this flag is used.
|