Re: DatabaseWrapper.needs_rollback and transaction.rollback()

[Mark Young]

I created an issue for this https://code.djangoproject.com/ticket/27504 , 
and created a pull request as well: 
https://github.com/django/django/pull/7577.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57bdf4b6-c53f-4af8-8d34-0af474d1772c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

[Mark Young]

Re fixing transaction.rollback: What would be the preferred way to fix 
this? I haven't personally tested it (a coworker has and reports that it 
doesn't work), but BaseDatabaseWrapper.set_rollback requires that 
in_atomic_block be True when set_rollback is called, which is not the case 
in this example or in general, I think (I still don't entirely know what 
in_atomic_block is really supposed to mean). I could manually do 
get_connection(using).needs_rollback = False . 

Once I know the preferred fix, I'll work on the patch. 

One thing I still don't understand is why needs_rollback was set to True in 
the first place in my simple example. Reading the attribute name naively, 
we don't really need to emit a db rollback at all, as the bad save never 
hit the db at all, as it failed in the model validations. (In practice, 
this doesn't matter too much, as there's no real harm in making 
unneeded-as-far-as-the-db-is-concerned rollback calls. Asking more in hopes 
of understanding what's going on better)

Thanks for the help

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/671da620-cdd9-48ed-9645-258682874117%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DatabaseWrapper.needs_rollback and transaction.rollback()

[Mark Young]

 After a validationError occurs, why is the transaction considered dirty, 
blocking all db reads/writes? In this example: 
https://bitbucket.org/marky1991/django-test/raw/59c9ff89e4b12b4a831c36171139cb022735201b/test1.py
 
, I don't really expect a TransactionManagementError at all, as the failure 
in question is a django model ValidationError, so no rollback should be 
needed, since the save never actually hits the db. At the minimum, however, 
I would expect a transaction.rollback() to resolve the issue, but it does 
not. 

The traceback: https://dpaste.de/ooTy

Is there a django bug here or are my expectations not correct?

I have found this: https://code.djangoproject.com/ticket/26340 , where Aymeric 
Augustin said that he thought that transaction.rollback should indeed set 
DatabaseWrapper.needs_rollback to False, as I would expect.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df66a920-2537-48dc-a0e2-4db2de5a54fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Contenttypes.GenericForeignKey Docs Addition

[Mark Young]

I'm not sure if my patch is sufficiently clear (it's only two words), but 
I've created a patch and ticket 
here
.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Contenttypes.GenericForeignKey Docs Addition

[Mark Young]

Could it be mentioned that GenericForeignKey fields can't be accessed in 
forms in the docs? Without stackoverflow, I would've probably never figured 
this out. When you try to access it through the form, all you get is a 
FieldError saying that the model doesn't even have the field you're looking 
for. (Which isn't completely true, as it can be used elsewhere) 

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Support Negative Indexing on QuerySets

[Mark Young]

In this support ticket (https://code.djangoproject.com/ticket/13089), the 
original closer said "This is a long-standing explicit design decision in 
the ORM, and so gets a wontfix...". What is the reasoning behind this? Why 
is negative indexing of querysets disallowed?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.