Re: What is the correct behavior? [was: new backend: unit test ...]

[Russell Keith-Magee]

On Thu, Jul 1, 2010 at 8:05 PM, Mark Bucciarelli  wrote:
> On Wed, Jun 30, 2010 at 7:14 PM, Russell Keith-Magee
>  wrote:
>>
>> It appears that MonetDB is behaving the same way as PostgreSQL. The
>> right approach in the test is to catch the exception and roll back the
>> cursor.
>>
>
> In 1.2 I see full_clean() and ValidationError let's
> me handle this in application code in a way that
> is independent of the backend.
>
> Is there a 1.1 way to do this so I don't have to
> know the backend so I can catch the right
> exception?
>
> I couldn't figure out anyway to do this inside
> the db driver.

1.1 provides an alias for the underlying database IntegrityError and
DatabaseError. This means you can import

from django.db import IntegrityError

which allows you to catch IntegrityError (as in, you can have a
try/except block and you don't need to change code on a per-backend
basis), but you can't rely on the internal implementation of the
exception being consistent.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What is the correct behavior? [was: new backend: unit test ...]

[Mark Bucciarelli]

On Wed, Jun 30, 2010 at 7:14 PM, Russell Keith-Magee
 wrote:
>
> It appears that MonetDB is behaving the same way as PostgreSQL. The
> right approach in the test is to catch the exception and roll back the
> cursor.
>

In 1.2 I see full_clean() and ValidationError let's
me handle this in application code in a way that
is independent of the backend.

Is there a 1.1 way to do this so I don't have to
know the backend so I can catch the right
exception?

I couldn't figure out anyway to do this inside
the db driver.

Thanks,

m

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: What is the correct behavior? [was: new backend: unit test ...]

[Russell Keith-Magee]

On Thu, Jul 1, 2010 at 2:19 AM, Mark Bucciarelli  wrote:
> On Wed, Jun 30, 2010 at 7:56 AM, Mark Bucciarelli  wrote:
>> On Wed, Jun 30, 2010 at 7:14 AM, Mark Bucciarelli  wrote:
>>>
>>> Is this test look correct?
>>>
>>
>> It passes when using SQLite ...
>>
>
> It fails with a postgresql_pschopg2 backend.
>
> So what is the correct Django backend behavior?
>
> Here's the relevant part of test script I'm using.
> PostgreSQL fails on the get() call near the end.
>
>        names = ('a', 'b')
>        for name in names:
>                try:
>                        s = Source.objects.get(name=name)
>                        s.delete()
>                except Source.DoesNotExist:
>                        pass
>                s = Source(name=name, feedurl=name)
>                s.save()
>        try:
>                s = Source(name=names[0], feedurl=names[0])
>                s.save()
>        except IntegrityError:
>                pass
>        s = Source.objects.get(name=names[1])
>        print s
>
> The error is very similar to MonetDB:
>
>        psycopg2.InternalError: current transaction is
>        aborted, commands ignored until end of transaction
>        block

What is happening here is the surfacing of a difference between the
way PostgreSQL handles exceptions and the way SQLite handles
exceptions. As is to be expected, SQLite is a simple database, so it's
transaction control isn't as robust as a production-ready database.

When you generate an error under PostgreSQL, the cursor is put into an
error state, and in the interests of protecting you, it prevents you
from doing anything else with that cursor until the problem is
resolved. This means you have to roll back the cursor to the last
commit.

Strictly, the same problem exists with SQLite (i.e., you've
experienced an error that needs to be handled); but SQLite doesn't
force you to roll back the transaction and clarify that the problem
has been resolved.

It appears that MonetDB is behaving the same way as PostgreSQL. The
right approach in the test is to catch the exception and roll back the
cursor.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[solved] What is the correct behavior? [was: new backend: unit test ...]

[Mark Bucciarelli]

On Wed, Jun 30, 2010 at 2:19 PM, Mark Bucciarelli  wrote:
>
> So what is the correct Django backend behavior?
>

I'm going with backend-dependent for
pre-1.2 Django.

In 1.2 full_clean() + ValidationError is
to the rescue.

Thanks,

m

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

What is the correct behavior? [was: new backend: unit test ...]

[Mark Bucciarelli]

On Wed, Jun 30, 2010 at 7:56 AM, Mark Bucciarelli  wrote:
> On Wed, Jun 30, 2010 at 7:14 AM, Mark Bucciarelli  wrote:
>>
>> Is this test look correct?
>>
>
> It passes when using SQLite ...
>

It fails with a postgresql_pschopg2 backend.

So what is the correct Django backend behavior?

Here's the relevant part of test script I'm using.
PostgreSQL fails on the get() call near the end.

names = ('a', 'b')
for name in names:
try:
s = Source.objects.get(name=name)
s.delete()
except Source.DoesNotExist:
pass
s = Source(name=name, feedurl=name)
s.save()
try:
s = Source(name=names[0], feedurl=names[0])
s.save()
except IntegrityError:
pass
s = Source.objects.get(name=names[1])
print s

The error is very similar to MonetDB:

psycopg2.InternalError: current transaction is
aborted, commands ignored until end of transaction
block

Thanks,

Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.