| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
as possible
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
reason py3k's pickle seems to be OK? not sure why that is, as this
is all related to http://bugs.python.org/issue998998
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
encoded in them vs. unicode escaping. not worth figuring out how to combine
these right now
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
- went through examples/ and cleaned out excess list() calls
|
| | |/
|/| |
|
| |/
|
|
|
|
| |
being sent to :func:`.create_engine` would fail in some cases,
such as with the Sybase dialect.
[ticket:2732]
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
a rollback() before re-raising, so that the stack
trace is preserved from sys.exc_info() before entering
the rollback. This so that the traceback is preserved
when using coroutine frameworks which may have switched
contexts before the rollback function returns.
[ticket:2703]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
labeled columns when apply_labels() is used; this mode
produces a SELECT where each column is labeled as in
<tablename>_<columnname>, to remove column name collisions
for a multiple table select. The fix is that if two labels
collide when combined with the table name, i.e.
"foo.bar_id" and "foo_bar.id", anonymous aliasing will be
applied to one of the dupes. This allows the ORM to handle
both columns independently; previously, 0.7
would in some cases silently emit a second SELECT for the
column that was "duped", and in 0.8 an ambiguous column error
would be emitted. The "keys" applied to the .c. collection
of the select() will also be deduped, so that the "column
being replaced" warning will no longer emit for any select()
that specifies use_labels, though the dupe key will be given
an anonymous label which isn't generally user-friendly.
[ticket:2702]
|
| |
|
|
| |
the `b` notation for byte string literals)
|
| |
|
|
|
|
| |
- other cleanup
- don't need compat.decimal, that approach never panned out. hopefully
outside libs aren't pulling it in, they shouldn't be
|
| | |
|
| |
|
|
|
|
|
|
|
| |
:class:`.CheckConstraint` would apply itself back to the
original table during a :meth:`.Table.tometadata` operation, as
it would parse the SQL expression for a parent table. The
operation now copies the given expression to correspond to the
new table.
[ticket:2633]
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
exceptions in the None labels case, but rather return (), [], or {}. this is not backwards compatible, but doubt anyone is relying on those exceptions #2601
|
| | |
|
| |
|
|
| |
anything
|
| | |
|
| |
|
|
|
|
|
|
|
| |
that works in terms of the "impl" type by default.
This is a behavioral change for those TypeDecorator
classes that specify a custom __init__ method; those
types will need to re-define __repr__() if they need
__repr__() to provide a faithful constructor representation.
[ticket:2594]
|
| | |
|
| |
|
|
|
|
| |
__dict__.pop(),
remove reset_memoized
|
| |
|
|
|
|
|
|
| |
is replaced, such as via extend_existing,
the "auto increment" column used by insert()
constructs is reset. Previously it would
remain referring to the previous primary
key column. [ticket:2525]
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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].
|
| |
|
|
|
| |
the "name" and "native_enum" flags. Helps
Alembic autogenerate.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
- fix this test
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
inheriting mappers to be GC'ed when the
class itself is deferenced. The mapper
must not have its own table (i.e.
single table inh only) without polymorphic
attributes in place.
This allows for the use case of
creating a temporary subclass of a declarative
mapped class, with no table or mapping
directives of its own, to be garbage collected
when dereferenced by a unit test.
[ticket:2526]
|
| | |
|
| | |
|
| |
|
|
| |
continuing [ticket:2522]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and the entire related system of alternate
class implementation is now moved out
to sqlalchemy.ext.instrumentation. This is
a seldom used system that adds significant
complexity and overhead to the mechanics of
class instrumentation. The new architecture
allows it to remain unused until
InstrumentationManager is actually imported,
at which point it is bootstrapped into
the core.
|
