Connection creation was done in db backend ._cursor() call. This
included taking a new connection if needed, initializing the session
state for the new connection and finally creating the connection.
To allow easier modifying of these steps in subclasses (for example to
support connection pools) the _cursor() now calls get_new_connection()
and init_connection_state() if there isn't an existing connection. This
was done for all non-gis core backends. In addition the parameters used
for taking a connection are now created by get_connection_params().
We should also do the same for gis backends and encourage 3rd party
backends to use the same pattern. The pattern is not enforced in code,
and as the backends are private API this will not be required by
documentation either.
Previously, the flush was done before the test case execution and now
it is performed after it.
Other changes to the testing infrastructure include:
* TransactionTestCase now doesn't reset autoincrement sequences either
(previous behavior can achieved by using `reset_sequences`.)
With this, no implicit such reset is performed by any of the provided
TestCase classes.
* New ordering of test cases: All unittest tes cases are run first and
doctests are run at the end.
THse changes could be backward-incompatible with test cases that relied
on some kind of state being preserved between tests. Please read the
relevant sections of the release notes and testing documentation for
further details.
Thanks Andreas Pelme for the initial patch. Karen Tracey and Anssi
Kääriäinen for the feedback and Anssi for reviewing.
This also fixes#12408.
Fixed#15933, #18082 -- the get_indexes() method introspection was
done inconsitently depending on the backend. For example SQLite
included all the columns in the table in the returned dictionary,
while MySQL introspected also multicolumn indexes.
All backends return now consistenly only single-column indexes.
Thanks to andi for the MySQL report, and ikelly for comments on
Oracle's get_indexes() changes.
Thanks bthomas AT ncorcle DOT com for the report and initial patch, and
Claude Paroz for the final, complete patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17508 bcc190cf-cafb-0310-a4f2-bffc1f526a37
only consider some fields (PostgreSQL only).
For this, the ``distinct()`` QuerySet method now accepts an optional
list of model fields names and generates ``DISTINCT ON`` clauses on
these cases. Thanks Jeffrey Gelens and Anssi Kääriäinen for their work.
Fixes#6422.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17244 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Implemented this by adding an internal hook for work that should be performed
before that point.
Also, regarding the `DatabaseCreation.set_autocommit()` method:
* Stop using it for such tasks
* Stop providing an implementation that tries to cover all the possible
idioms a third party database backend DB-API 2 driver could need to activate
autocommit. It is now left for third party backends to implement.
This can be backwards incompatible in the case of user applications that:
* Had started using this method
* Use a third a party database backend
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16520 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Changed our internal representation of the PostgreSQL version from tuples to
integers as used by libpq and psycopg2. This simplifies version comparison
operations.
Also, using the associated libpq/psycopg2 API allows to remove the need for
manually issuing in-band ``SELECT version()`` SQL queries to obtain the server
version (or at least reduce its number if version of psycopg2 in use is older
than 2.0.12). Refs #10509.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16439 bcc190cf-cafb-0310-a4f2-bffc1f526a37
A number of people worked on this patch over the years -- Hawkeye, Colin Grady,
KBS, sakyamuni, anih, jdemoor, and Issak Kelly. Thanks to them all, and
apologies if I missed anyone.
Special thanks to Dan Fairs for picking it up again at the end and seeing this
through to commit.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16058 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The unification had been introduced in r12352 and native backend exceptions still
slipped through in cases that end in connection.commit() call. Thanks Alex,
Jacob and Carl for reviewing.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14320 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This monster of a patch is the result of Alex Gaynor's 2009 Google Summer of Code project.
Congratulations to Alex for a job well done.
Big thanks also go to:
* Justin Bronn for keeping GIS in line with the changes,
* Karen Tracey and Jani Tiainen for their help testing Oracle support
* Brett Hoerner, Jon Loyens, and Craig Kimmerer for their feedback.
* Malcolm Treddinick for his guidance during the GSoC submission process.
* Simon Willison for driving the original design process
* Cal Henderson for complaining about ponies he wanted.
... and everyone else too numerous to mention that helped to bring this feature into fruition.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11952 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Affects the postgresql_psycopg2 backend only. We now don't use the
"RETURNING" syntax in SQL INSERT statements unless it's required by the
autocommit behaviour. This fixes an edge-case that could cause crashes
with earlier PostgreSQL versions, but the broader problem remains to be
fixed (which is #10509).
Fixed#10467. Refs #10509.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10065 bcc190cf-cafb-0310-a4f2-bffc1f526a37
I introduced a bad regression in r10029, forgetting to check that some
syntax was supported. For now, you can't use autocommit=True with 8.1
and earlier (it's still available for later versions). I'll fix the
broader issue later and re-enable it for those versions, but I want to
get the SQL regression for the default path out of the code right now.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10035 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There was a bug in the way we were reading the DATABASE_OPTIONS setting
and a lot of essentially duplicated code. This is neater.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10033 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Ensure to read the documentation before blindly enabling this: requires some
code audits first, but might well be worth it for busy sites.
Thanks to nicferrier, iamseb and Richard Davies for help with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10029 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is backwards-compatible but will likely break third-party database backends. Specific API changes are:
* BaseDatabaseWrapper.__init__() now takes a settings_dict instead of a settings module. It's called settings_dict to disambiguate, and for easy grepability. This should be a dictionary containing DATABASE_NAME, etc.
* BaseDatabaseWrapper has a settings_dict attribute instead of an options attribute. BaseDatabaseWrapper.options is now BaseDatabaseWrapper['DATABASE_OPTIONS']
* BaseDatabaseWrapper._cursor() no longer takes a settings argument.
* BaseDatabaseClient.__init__() now takes a connection argument (a DatabaseWrapper instance) instead of no arguments.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10026 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is a no-op for most databases. Only necessary on PostgreSQL so that we can
do things which will possibly intentionally raise an IntegrityError and not
have to rollback the entire transaction. Not supported for PostgreSQL versions
prior to 8.0, so should be used sparingly in internal Django code.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8314 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Anssi Kääriäinen
Andrew Godwin
Claude Paroz
Aymeric Augustin
Ramiro Morales
Julien Phalip
Alex Gaynor
Honza Král
Karen Tracey
Jannis Leidel
Jacob Kaplan-Moss
Russell Keith-Magee
Carl Meyer
Justin Bronn
Malcolm Tredinnick
Ian Kelly
Adrian Holovaty
Gary Wilson Jr