On Thu, Jul 14, 2011 at 2:36 PM, Jim Dalton wrote:
> So in normal, everyday use, Django opens a connection to Postgresql with an
> open transaction. Per the docs, it commits this transaction immediately
> whenever you do an INSERT or UPDATE etc. At that point Postgresql would run
> its constraint
On Jul 14, 2011, at 1:31 AM, Simon Riggs wrote:
> On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton wrote:
>> On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
>>
>>> Maintaining the property of deferrable constraints seems important
>>> here, so changing the deferrability of constraints, or overriding
On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton wrote:
> On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
>
>> Maintaining the property of deferrable constraints seems important
>> here, so changing the deferrability of constraints, or overriding it
>> using the SET CONSTRAINTS command at the top of th
On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
> Maintaining the property of deferrable constraints seems important
> here, so changing the deferrability of constraints, or overriding it
> using the SET CONSTRAINTS command at the top of the transaction might
> not be what we want.
Well, that's j
On Sun, Jul 10, 2011 at 5:35 AM, Jim D. wrote:
> The problem is that by default in most of our backends, a transaction runs
> with constraint checks deferred. This means that foreign keys are *not*
> checked for integrity until a transaction is committed. But here's the rub:
> we never commit a t
Howdy,
I'd like to share some findings I made recently with regards to deferred
constraint checks during test runs. There's a bit of background here
(https://code.djangoproject.com/ticket/3615) and
here(https://code.djangoproject.com/ticket/11665), but this is the gist of
what's going on now:
