| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Fixes #2821
|
| |
|
|
| |
filters applied.
|
| | |
|
| |
|
|
| |
in-python only cols
|
| |
|
|
|
|
| |
of the incoming :class:`.Column` would prevent primary key constraints,
indexes, and foreign key constraints from being correctly reflected.
Also in 0.8.3. [ticket:2811]
|
| |
|
|
| |
- callcount
|
| | |
|
| |
|
|
| |
quoting the lowercase name.
|
| |
|
|
|
|
| |
--write-profiles is set
- some sqlite callcounts
|
| | |
|
| |
|
|
| |
- cx_oracle dialect doesn't use normal col names, lets just not rely on that for now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of relying upon various ``quote=True`` flags being passed around,
these flags are converted into rich string objects with quoting information
included at the point at which they are passed to common schema constructs
like :class:`.Table`, :class:`.Column`, etc. This solves the issue
of various methods that don't correctly honor the "quote" flag such
as :meth:`.Engine.has_table` and related methods. The :class:`.quoted_name`
object is a string subclass that can also be used explicitly if needed;
the object will hold onto the quoting preferences passed and will
also bypass the "name normalization" performed by dialects that
standardize on uppercase symbols, such as Oracle, Firebird and DB2.
The upshot is that the "uppercase" backends can now work with force-quoted
names, such as lowercase-quoted names and new reserved words.
[ticket:2812]
|
| |
|
|
| |
unittest.TestCase
|
| | |
|
| |
|
|
|
| |
- modernize test for that
- use py3k compatible next() in test_returning/test_versioning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to rely upon server generated version identifiers, using triggers
or other database-provided versioning features, by passing the value
``False``. The ORM will use RETURNING when available to immediately
load the new version identifier, else it will emit a second SELECT.
[ticket:2793]
- The ``eager_defaults`` flag of :class:`.Mapper` will now allow the
newly generated default values to be fetched using an inline
RETURNING clause, rather than a second SELECT statement, for backends
that support RETURNING.
- Added a new variant to :meth:`.ValuesBase.returning` called
:meth:`.ValuesBase.return_defaults`; this allows arbitrary columns
to be added to the RETURNING clause of the statement without interfering
with the compilers usual "implicit returning" feature, which is used to
efficiently fetch newly generated primary key values. For supporting
backends, a dictionary of all fetched values is present at
:attr:`.ResultProxy.returned_defaults`.
- add a glossary entry for RETURNING
- add documentation for version id generation, [ticket:867]
|
| |
|
|
|
| |
Conflicts:
lib/sqlalchemy/schema.py
|
| |
|
|
| |
with CreateColumn rules
|
| |
|
|
|
| |
compilation rule which allows skipping of columns, by producing
a rule that returns ``None``. Also in 0.8.3.
|
| |
|
|
|
|
|
|
| |
setslice of ``[0:0]`` correctly, which in particular could occur
when using ``insert(0, item)`` with the association proxy. Due
to some quirk in Python collections, the issue was much more likely
with Python 3 rather than 2. Also in 0.8.3, 0.7.11.
[ticket:2807]
|
| |
|
|
| |
- fix and test weakref cleanout for WeakSequence, [ticket:2794]
|
| |
|
|
|
| |
not be properly quoted if it was referred to in multiple FROM clauses.
Also in 0.8.3, 0.7.11. [ticket:2801]
|
| | |
|
| |
|
|
| |
access
|
| | |
|
| |
|
|
| |
courtesy Hajime Nakagami.
|
| |
|
|
|
|
|
|
|
| |
- rework the event system so that event modules load after their
targets, dependencies are reversed
- create an improved strategy lookup system for the ORM
- rework the ORM to have very few import cycles
- move out "importlater" to just util.dependency
- other tricks to cross-populate modules in as clear a way as possible
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the import structure of many core modules.
``sqlalchemy.schema`` and ``sqlalchemy.types``
remain in the top-level package, but are now just lists of names
that pull from within ``sqlalchemy.sql``. Their implementations
are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``,
``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was
moved from ``sqlalchemy.engine``. ``sqlalchemy.sql.expression`` is also
a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``,
``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``.
Most of the "factory" functions
used to create SQL expression objects have been moved to classmethods
or constructors, which are exposed in ``sqlalchemy.sql.expression``
using a programmatic system. Care has been taken such that all the
original import namespaces remain intact and there should be no impact
on any existing applications. The rationale here was to break out these
very large modules into smaller ones, provide more manageable lists
of function names, to greatly reduce "import cycles" and clarify the
up-front importing of names, and to remove the need for redundant
functions and documentation throughout the expression package.
|
| |
|
|
|
| |
produces the negation of the expression "IN" returns
when used against an empty collection. Also in 0.8.3.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
proxies, they aren't overriding getattr() or setattr() at all. so all the
hardcoded getattr()/setattr() is removed from collections.py. Lots of these
getattr/setattr were against the attributeimpl and decorated functions
and don't seem like they'd ever be needed; for a user that needs special access
to a collection, we can evaulate that use case and add a single point of
"unwrapping", and probably add a hook for it via
InstrumentationManager so that the collection implementation isn't complicated
by it.
|
| | |
|
| |
|
|
|
| |
before we do the pop() test.
- make clear()/pop() test unconditional
|
| |
|
|
|
|
|
|
| |
this is a dictionary where applications can store arbitrary
data local to a :class:`.Session`.
The contents of :attr:`.Session.info` can be also be initialized
using the ``info`` argument of :class:`.Session` or
:class:`.sessionmaker`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ideas in general:
- pypy2.1 w/ sqlite3 is the first DBAPI we're seeing returning
unicode in cursor.description without being py3k. add a new on-connect
check for this, if we get back a u"", just don't do description decoding,
should be OK for now.
- the set tests in test_collection were assuming the two sets would be ordered
the same when it tested pop(), can't really assume that.
- test_serializer gets worse and worse, pickle is just not really viable here,
ding out pypy
- pypy2.1b2 seems to allow cursor.lastrowid to work (or we changed something?)
- pool._threadconns.current() is a weakref, it can be None
- another one of those logging.handlers imports
|
| |
|
|
|
|
| |
used only as an ``alias()`` construct, it would not render using the
WITH keyword. Also in 0.8.3, 0.7.11.
[ticket:2783]
|
| | |
|
| |
|
|
|
|
| |
are transferred correctly for when .key is present; tests have been enhanced
to test this condition for render, result map construction, statement
execution. [ticket:2790]
|
| |
|
|
| |
any supported CPython 2 or 3 environment. [ticket:2161]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
provided via the :func:`.event.remove` function.
[ticket:2268]
- reorganization of event.py module into a package; with the addition of the
docstring work as well as the new registry for removal, there's a lot more code now.
the package separates concerns and provides a top-level doc for each subsection
of functionality
- the remove feature works by providing the EventKey object which associates
the user-provided arguments to listen() with a global, weak-referencing registry.
This registry stores a collection of _ListenerCollection and _DispatchDescriptor
objects associated with each set of arguments, as well as the wrapped function
which was applied to that collection. The EventKey can then be recreated for
a removal, all the _ListenerCollection and _DispatchDescriptor objects are located,
and the correct wrapped function is removed from each one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
:class:`.AttributeImpl` as an "initiator" token has been changed;
the object is now an event-specific object called :class:`.attributes.Event`.
Additionally, the attribute system no longer halts events based
on a matching "initiator" token; this logic has been moved to be
specific to ORM backref event handlers, which are the typical source
of the re-propagation of an attribute event onto subsequent append/set/remove
operations. End user code which emulates the behavior of backrefs
must now ensure that recursive event propagation schemes are halted,
if the scheme does not use the backref handlers. Using this new system,
backref handlers can now peform a
"two-hop" operation when an object is appended to a collection,
associated with a new many-to-one, de-associated with the previous
many-to-one, and then removed from a previous collection. Before this
change, the last step of removal from the previous collection would
not occur.
[ticket:2789]
|
| |
|
|
|
|
| |
"propagate" flags could potentially be mis-configured in some
"unmapped base class" configurations. Also in 0.8.3.
[ticket:2786]
|
| |
|
|
|
| |
:class:`.Column` object would not be propagated. Also in 0.8.3, 0.7.11.
[ticket:2784]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
when loading mapped entities. The function overhead of applying
a per-object deferred callable to an instance at load time was
significantly higher than that of just loading the data from the row
(note that ``defer()`` is meant to reduce DB/network overhead, not
necessarily function call count); the function call overhead is now
less than that of loading data from the column in all cases. There
is also a reduction in the number of "lazy callable" objects created
per load from N (total deferred values in the result) to 1 (total
number of deferred cols).
[ticket:2778]
|
| |
|
|
|
|
|
| |
regexp apparently were not fully implemented correctly; while the
arguments were accepted, in practice they would have no effect;
this has been fixed. Also in 0.8.3.
[ticket:2781]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
form of a some expressions when referring to the ``.c`` collection
on a ``select()`` construct, but the ``str()`` form isn't available
since the element relies on dialect-specific compilation constructs,
notably the ``__getitem__()`` operator as used with a Postgresql
``ARRAY`` element. The fix also adds a new exception class
:class:`.UnsupportedCompilationError` which is raised in those cases
where a compiler is asked to compile something it doesn't know
how to. Also in 0.8.3.
[ticket:2780]
|