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.

- went through examples/ and cleaned out excess list() calls

  subclass could insert the row for the "sub" table
  before the parent table, if the two tables had no
  ForeignKey constraints set up between them.
  Also in 0.7.11. [ticket:2689]
- fix a glitch in the assertsql.CompiledSQL fixture regarding
when a multiparam compiledSQL is used within an AllOf
- add a new utility function randomize_unitofwork() which
does the function of --reversetop

you get "import test" as what it tries to run with
setup.py test

- start filling in default versions of remaining requirements that are still only in test/

to a DBLINK remote database; while the syntax has been present in the
Oracle dialect for some time, up until now it has never been tested.
The syntax has been tested against a sample database linking to itself,
however there's still some uncertainty as to what should be used for the
"owner" when querying the remote database for table information.
Currently, the value of "username" from user_db_links is used to
match the "owner".  [ticket:2619]

actually run the test
- add requirements for date/datetime/time capabilities
- remove test/sql/test_types->DateTest and create new tests in suite/test_types
- move the StringTest with the "no length create" test to the suite, though this is a
weird test

    API to better support highly specialized
    systems such as the Akiban database, including
    more hooks to allow an execution context to
    access type processors.