We need to know the number of rows that are matched by an UPDATE query,
not just the number of rows that are changed. In the relatively unlikely
event that somebody was using Django's cursor proxy and relying on the
previous behaviour, well, that isn't the case any longer. We need to
this version.
Thanks to Daniel Tang for pointing out the solution here.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10532 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We now pass numbers used in data queries as actualy numbers (integers) to the
database backends, rather than string forms. This is easier for some of the
less flexible backeds.
Based on a patch from Leo Soto and Ramiro Morales.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10530 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
In order to report more comphrehensible tracebacks, remove the super()
constructor call, since passing args to object.__init__ ends badly. So some
subclassing possibilities are now removed, but it's the "dummy" backend, so
we can make some compromises.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10042 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 allows a model to be defined which is not subject to database table
creation and removal. Useful for models that sit over existing tables or
database views.
Thanks to Alexander Myodov, Wolfgang Kriesing and Ryan Kelly for the bulk of
this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10008 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Allows us to reuse the same code in multiple places, avoiding new and
interesting bugs (the testing framework had a DIY version that was slightly
wrong, for example). Fixed#9833.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9936 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This change may be slightly backwards incompatible, if existing tests need to test transactional behavior, or if they rely on invalid assumptions or a specific test case ordering. For the first case, django.test.TransactionTestCase should be used. TransactionTestCase is also a quick fix to get around test case errors revealed by the new rollback approach, but a better long-term fix is to correct the test case. See the testing doc for full details.
Many thanks to:
* Marc Remolt for the initial proposal and implementation.
* Luke Plant for initial testing and improving the implementation.
* Ramiro Morales for feedback and help with tracking down a mysterious PostgreSQL issue.
* Eric Holscher for feedback regarding the effect of the change on the Ellington testsuite.
* Russell Keith-Magee for guidance and feedback from beginning to end.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9756 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Russell Keith-Magee
Matt Boersma
Malcolm Tredinnick
Jacob Kaplan-Moss
Karen Tracey
Justin Bronn
Ian Kelly
Adrian Holovaty