| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
|
| |
|
|
|
|
|
|
|
|
|
| |
- bootstrap and lib move to all absolute imports
- testing.py is no longer internally referenced.
- requirements move to be a pluggable class which can
be overridden.
- cleanup
in the interests of third party testing, test/lib and test/bootstrap
may move to be an independent package.
|
| | |
|
| |
|
|
|
|
| |
- enhancements to test suite including ability to set up a testing engine
for a whole test class, fixes to how noseplugin sets up/tears
down per-class context
|
| |
|
|
| |
[ticket:2461]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more lenient as to the table
being updated. Plain Table objects are better
supported now, and additional a joined-inheritance
subclass may be used with update(); the subclass
table will be the target of the update,
and if the parent table is referenced in the
WHERE clause, the compiler will call upon
UPDATE..FROM syntax as allowed by the dialect
to satisfy the WHERE clause. Target columns
must still be in the target table i.e.
does not support MySQL's multi-table update
feature (even though this is in Core).
PG's DELETE..USING is also not available
in Core yet.
|
| |
|
|
|
|
|
|
|
| |
loading dealing with chains of subclass entities
sharing a common base, with no specific "join depth"
provided. Will chain out to
each subclass mapper individually before detecting
a "cycle", rather than considering the base class
to be the source of the "cycle". [ticket:2481]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the benefit of the test.lib.schema package.
- use test.lib.schema.Table for the table within test.lib.fixtures.DeclarativeMappedTest
- [bug] Removed the check for number of
rows affected when doing a multi-delete
against mapped objects. If an ON DELETE
CASCADE exists between two rows, we can't
get an accurate rowcount from the DBAPI;
this particular count is not supported
on most DBAPIs in any case, MySQLdb
is the notable case where it is.
[ticket:2403]
|
| |
|
|
|
|
|
|
|
|
| |
in the corresponding selectable to take into account clones
of the target column. fixes [ticket:2419]
- have _make_proxy() copy out the _is_clone_of attribute on the
new column so that even more corresponding_column() checks
work as expected for cloned elements.
- add a new test fixture so that mapped tests can be specified
using declarative.
|
| |
|
|
|
|
| |
- remove extra _load_fixtures() method. using the classbound version as the fixtures
seem to have everything classlevel at the moment (wondering if we want to change that
for non-classlevel setup/teardown)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method of
creating fixture classes the same, i.e. run a method, then inspect __subclasses__() of
a marked base class, seems to have broken that approach permanently. While the tests run
locally just fine, on the buildbot most of the environments continue to fail in entirely
random places. One of the key changes of the reorganization is that the big bunch of
classes from _fixtures.py is now created ad-hoc instead of reusing a set of module-bound
classes. This means there's a lot more class creation/teardown traffic occuring in the
cPython interpreter. Taking a look at the docs for __subclasses__() confirms that the
list of subclasses is of course a weak-referenced collection. So in the absense of the
tests working just fine for a couple of years, it would seem obvious that the bug
here is setup_classes()/mappers() is called, we come back, the new classes are now
not referenced at all, we then call __subclasses__() and maybe we get them, maybe we don't.
But it's totally not clear how this behavior just hasn't occurred at all for a couple
of years (except, possibly, for very rare occasions that I cannot reproduce). So in this changeset we switch
to a method of class tracking that I use in a lot of other places, that of using a metaclass
to positively stick classes in the registry the moment they are created. Test classes
are already built against a base that is created per-fixture run so we already have the advantage
of a local system. I send this changeset to the buildbot and beg of it to please allow our
tests to pass once again !
|
| | |
|
|
|
classes to a new test.lib.fixtures module
- move testing.TestBase to test.lib.fixtures
- massive search and replace
|
