sqlalchemy / README.dialects.rst

Diff from to

README.dialects.rst

 to grow and mature it should become a more thorough and efficient system
 of testing new dialects.
 
+Dialect Layout
+===============
+
 The file structure of a dialect is typically similar to the following::
 
     sqlalchemy-<dialect>/
 An example of this structure can be seen in the Access dialect at
 https://bitbucket.org/zzzeek/sqlalchemy-access/.
 
-Key aspects of this file layout include::
+Key aspects of this file layout include:
 
 * setup.py - should specify setuptools entrypoints, allowing the
-  dialect to be usable from create_engine(), e.g.:
+  dialect to be usable from create_engine(), e.g.::
 
         entry_points={
          'sqlalchemy.dialects': [
               ]
         }
 
-Above, the two entrypoints ``access`` and ``access.pyodbc`` allow URLs to be
-used such as::
+  Above, the two entrypoints ``access`` and ``access.pyodbc`` allow URLs to be
+  used such as::
 
     create_engine("access://user:pw@dsn")
 
               # fixture
               return
 
+Going Forward
+==============
 
+The third-party dialect can be distributed like any other Python
+module on Pypi. Links to prominent dialects can be featured within
+SQLAlchemy's own documentation; contact the developers (see AUTHORS)
+for help with this.
+
+While SQLAlchemy includes many dialects built in, it remains to be
+seen if the project as a whole might move towards "plugin" model for
+all dialects, including all those currently built in.  Now that
+SQLAlchemy's dialect API is mature and the test suite is not far
+behind, it may be that a better maintenance experience can be
+delivered by having all dialects separately maintained and released.
+
+As new versions of SQLAlchemy are released, the test suite and
+requirements file will receive new tests and changes.  The dialect
+maintainer would normally keep track of these changes and make
+adjustments as needed.
+
+Continuous Integration
+======================
+
+The most ideal scenario for ongoing dialect testing is continuous
+integration, that is, an automated test runner that runs in response
+to changes not just in the dialect itself but to new pushes to
+SQLAlchemy as well.
+
+The SQLAlchemy project features a Jenkins installation that runs tests
+on Amazon EC2 instances.   It is possible for third-party dialect
+developers to provide the SQLAlchemy project either with AMIs or EC2
+instance keys which feature test environments appropriate to the
+dialect - SQLAlchemy's own Jenkins suite can invoke tests on these
+environments.  Contact the developers for further info.
+
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.