| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
"@", or "/" must be encoded." - so re-apply encoding to both password
and username, don't encode spaces as plus signs, don't encode any chars
outside of :, @, / on stringification - but we still parse for any
%XX character (is that right?)
|
| |
|
| |
|
|
|
|
| |
- 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]
|
| |
|
|
|
|
| |
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.
|
|
|
|
| |
we are pretty much back to the beginning, nothing to see here
|
|
|
|
| |
since we are dealing with cycles in any case.
|
| |
|
|
|
|
|
|
| |
is recreated, due to a disconnect error. This fixes a particular
issue in the Oracle 8 dialect, but in general the dialect.initialize()
phase should only be once per dialect. Also in 0.8.3. [ticket:2776]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with @_legacy_signature, will inspect incoming listener functions
to see if they match an older signature, will wrap into a newer sig
- add an event listen argument named=True, will send all args as
kw args so that event listeners can be written with **kw, any combination
of names
- add a doc system to events that writes out the various calling styles
for a given event, produces deprecation messages automatically.
a little concerned that it's a bit verbose but will look at it up
on RTD for awhile to get a feel.
- change the calling signature for bulk update/delete events - we have
the BulkUD object right there, and there's at least six or seven things
people might want to see, so just send the whole BulkUD in
[ticket:2775]
|
|
|
|
|
|
|
|
|
|
|
|
| |
actual mock objects from the mock library. I'd like to use mock
for new tests so we might as well use it in obvious places.
- use unittest.mock in py3.3
- changelog
- add a note to README.unittests
- add tests_require in setup.py
- have tests import from sqlalchemy.testing.mock
- apply usage of mock to one of the event tests. we can be using
this approach all over the place.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/dialects/postgresql/hstore.py
lib/sqlalchemy/util/__init__.py
lib/sqlalchemy/util/compat.py
|
| |
| |
| |
| | |
It's not the same as a dictionary as __iter__ does the values
|
| |
| |
| |
| | |
find some more failures
|
| |
| |
| |
| |
| | |
- illustrate how OrderedDict can catch these, but commented out
to save function overhead
|
| | |
|
| | |
|
| |
| |
| |
| | |
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]
|
| |
|
| |
|
| |
|