| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Convert to re.search to eliminate the restriction on only matching the
beginning of the string
|
|
|
|
| |
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
|
|
|
|
| |
- mention eager_defaults
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
Fixed two typos.
|
| | |
|
|/
|
|
|
| |
compilation rule which allows skipping of columns, by producing
a rule that returns ``None``. Also in 0.8.3.
|
|
|
|
|
|
|
|
| |
making _MapperEntity slightly less dependent on a particular parent
Query (in theory more shareable by multiple Query objects in different contexts)
- remove some comments that have been misunderstanding what _mapper_entities
does, or perhaps forgot to get removed
- simplify _mapper_entities
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
they're too big
- fix the targeting of module names moved around by using custom handlers for "Bases", etc.
|
| |
|
| |
|
|
|
|
| |
sorting in #2779
|
|
|
|
| |
- fix and test weakref cleanout for WeakSequence, [ticket:2794]
|
| |
|
|
|
|
|
|
|
| |
by the ORM to iterate mapper hierarchies; under the Jython interpreter
this implementation wasn't ordered, even though cPython and Pypy
maintained ordering. Also in 0.8.3.
[ticket:2794]
|
| |
|
|
|
|
|
|
| |
table
update, [ticket:2798]
|
|
|
|
|
| |
not be properly quoted if it was referred to in multiple FROM clauses.
Also in 0.8.3, 0.7.11. [ticket:2801]
|
| |
|
|
|
|
| |
access
|