Re: Testing related models without saving

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

--

Michael Herrmann, MSc

Alser Straße 18/26

1090 Wien

Tel.: +43 699 11 65 16 40

Email: michael@herrmann.io

--
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.

Re: Testing related models without saving

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/24147436-a0fa-49c8-bd80-e4e74d052319%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Does imports of related models affect cascade deletion?

No, import of related models shouldn't affect cascade deletion. Please open a bug report with steps to reproduce if that's actually the case. Possibly it could be a bug that's fixed by the app loading refactor in 1.7.

On Thursday, July 30, 2015 at 9:38:09 AM UTC-4, Markus Amalthea Magnuson wrote:

Hey,

I stumbled upon a piece of code and a comment that says this:

Deleting a model object that has related objects will only cascade delete those objects if their models have been imported.

Is this true? I have not found it in the documentation and would like to add a reference to the code comment so others won't be as confused as I am.

Here's an illustration (from memory, disregard if code is not valid python):

mymodel.py:

from django.db import models

class MyModel(models.Model):

    foo = models.CharField()

    bar = models.CharField()

my_other_model.py:

from django.db import models

from mymodel import MyModel

class MyOtherModel(models.Model):

    baz = models.CharField()

    bar = models.ForeignKey(MyModel)

some_source_file.py:

from mymodel import MyModel

# Without this line, deleting MyModel objects will not delete its related

# MyOtherModel objects (?):

from my_other_model import MyOtherModel

obj = MyModel.objects.get(pk=123)

obj.delete()

--
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/b41ea21c-aafb-4268-8549-93370000b0cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to save data from form FileField to DB Django

On Thu, Jul 30, 2015 at 10:40 AM, user07285 <j.arevathi@gmail.com> wrote:
> I have a model and have added a Form FileField to take a file and save all
> their contents for a particular object. The FileField doesn't need to be in
> the database hence not added as a model.fileField. The content from the file
> should be read , parsed and added to the synonym_type.


first of all, it's almost always a _terrible_ idea to save files in
database fields. Yes, it works, no, it's not "faster"; it creates a
heavy overhead on an already sensitive part of your system.

but, if you want to do it, the easiest way is to use a Storage Object
that manages the saving and thus you can keep the FieldFile
abstraction (either from a FileField or a File() object). Even
better, when you get to migrate to a different (better!) storage, you
only have to modify the settings and the code can stay the same.

check DjangoStorages [1], it includes a "Database" backend [2] (and
other like S3, libcloud, etc)

[1] https://django-storages.readthedocs.org/en/latest/index.html
[2] https://django-storages.readthedocs.org/en/latest/backends/database.html

--
Javier

--
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/CAFkDaoR4JMENcuHmTBxJApEG_nMC8sUCs92n%2B4QJ6iixckF8Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to save data from form FileField to DB Django

I have a model and have added a Form FileField to take a file and save all their contents for a particular object. The FileField doesn't need to be in the database hence not added as a model.fileField. The content from the file should be read , parsed and added to the synonym_type. 

**model.py** 

    molecule = models.ForeignKey('MoleculeDictionary', blank=False, null=False)

    synonym_type = models.ForeignKey('SynonymType')

                       

    synonym_name = models.CharField(max_length=50, blank=True)

    def __unicode__(self):

            return u'%s' % (self.synonym_name)

And this is how I add Form field to the models(admin)page. 

**form.py**

 

        from django.forms import ModelForm

        from django.forms import *

        import pdb

        import os

        from django.core.files.uploadedfile import SimpleUploadedFile

        from django.core.files import File

        from idg.models.molecule_synonym import MoleculeSynonym

        

        

        class MoleculeSynonymForm(ModelForm):

            file_upload = FileField(required=False)

            print "YES" 

            def save(self, commit=True):

                print 'saving...'

                file_upload = self.cleaned_data.get('file_upload', None)

                file_upload.seek(0)

                with open("../../Downloads/model_file_upload.txt", 'r') as f:

                    model_file = File(f)

                    names = model_file.read()

                    print(names)

        

                    form = MoleculeSynonymForm(names)

                    

                    return super(MoleculeSynonymForm, self).save(commit=commit)

                #

        

            class Meta:

                model = MoleculeSynonym

I have two questions: 

1. How should I save the names to the Synonym_name for a chosen synonym_type and molecule. I use sqlite. My current code doesn't throw any errors other than: 

> The molecule synonym "" was added successfully.

2. How do I get the "full path for the file" without hardcoding them in the open statement. 

--
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/338d22f3-8314-427d-9bf4-7f1412b89700%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two-to-Many Mapping between Models in Django ORM

2015-07-30 16:08 GMT+01:00 Rich Lewis <rich.lewis@gmx.co.uk>:

There are precisely 2 B instances associated with each A instance.  Each A instance can have many B instances

Isnt that a contradiction?

--

monoBOT

Visite mi sitio(Visit my site): monobotsoft.es/blog/

--
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/CA%2BxOsGBmQkMrNKu6f7pQC3WZ8SfHzDJF%2BbX7G45Lty%3D0aMLVdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Two-to-Many Mapping between Models in Django ORM

Dear All,

I'm new to the Django ORM, and quite new to ORMs in general.  I have two models (lets call them A and B) between which I have an interesting mapping.  There are precisely 2 B instances associated with each A instance.  Each A instance can have many B instances.  The order of Bs are important for As.

I want to do something like this:

class A(models.Model):

  b_1 = models.ForeignKey(B)

  b_2 = models.ForeignKey(B)

class B(models.Model):

  pass

Such that i can do:

>>> b1, b2, b3 = B(), B(), B()

>>> a1, a2 = A(b_1=b1, b_2=b2), A(b_1=b2, b_2=b3)

>>> b2.as

[<A ... >, <A ... >] #(order doesn't matter)

I expect I could eventually do something a bit hacky that would work, but what would be the best way to handle this?

Thanks in advance,

Richard

--
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/3250c3c4-7598-4104-8a7b-1a0aa313a253%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.