I'm very relieved - thanks Tim! If I can help, please let me know.
Best,
Michael
On 30 July 2015 at 17:56, Tim Graham <timograham@gmail.com> wrote:
We are working on that solution: https://github.com/django/django/pull/5060
On Thursday, July 30, 2015 at 7:19:31 AM UTC-4, mic...@herrmann.io wrote:Hi all,I've just been bitten by this new "feature" as well. I completely don't understand this design decision of 1.8. It is very useful to be able to create model classes without having to save them to the database, not just for unit tests but also for experimenting in the shell. The new "feature" breaks this which is a huge PITA, in my opinion.Could the check for RelatedObjectDoesNotExist not be performed in the save(...) method by Django? Then we would get the best of both worlds: You can create models however you like in unit tests or the shell, and at the same time if you erroneously attempt to save a foreign key which doesn't yet exist you would get the exception.I feel strongly about this because it is very much against the ease of use which I like so much about Django. Is this the appropriate forum to request this as a feature for 1.9 (or another future Django version)?Thanks,Michael
On Thursday, 16 July 2015 18:37:39 UTC+2, Carl Meyer wrote:Hi Roland,
On 07/16/2015 07:46 AM, Roland Swingler wrote:
>> i'll just say that Django tests don't favor too much into the "unit"
> test spectrum;
>
> That is what I'm seeing - it is the same with rails out of the box as
> well. I guess I'm just curious to know whether:
>
> a) the 'unit' test end of the spectrum is feasible if that's what you like
> b) what is available in the Django community (if anything, whether
> libraries, 'ways-of-doing-things' etc.) to support this if it is an
> approach one wants to take.
I also write model tests using unsaved models where possible. I don't
think it has significant test isolation benefits (your tests are still
integrating with most of the ORM), but it does have test-suite speed
benefits!
I understand why the change was made in 1.8 to disallow assigning an
unsaved object to a ForeignKey/OneToOneField attribute; in production
code that would almost always be a bug. Personally, though, I've never
been bitten by that bug, I'm confident I could easily find and fix such
a bug if I did write it, and I don't want to give up the ability to use
related unsaved models in tests. So I just use my own subclasses of
ForeignKey and OneToOneField with `allow_unsaved_instance_assignment =
True` set on them (essentially reverting the safety change in 1.8). I
haven't attempted to switch it on dynamically for testing; that should
be possible using a setting and a custom subclass, but I wouldn't choose
to do that; differences between test and production behavior should be
minimized.
Carl
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CABrKpmDpe1DzPDj0TtC--cLx%3DpuesGF_WbeESj7tkYLAMeTYSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment