Sven, I'm still looking at it myself. I'm trying to learn how to define and use Django models, in particular how to define and create a one-to-many relationship. It seems very counter-intuitive to me. I'll report back when and if I learn how to do that.
I take your earlier suggestion to mean that instead of creating a one-to-many relationship from the containing object to the objects that are contained in it, we should be creating a many-to-one relationship from the contained objects to the object that contains them. That seems to be the way Django wants us to do it, but it seems backwards to me. More later. Dave On Tue, Oct 31, 2017 at 11:12:45PM +0100, Sven Prevrhal wrote: > Thanks very much Dave, > I will dig into this further, code a little bit, let's stay in touch. If I > come up with something good, I'll send you a patch. > Cheers, > Sven > 2017-10-31 0:49 GMT+01:00 Dave Kuhlman <dkuhl...@davekuhlman.org>: > > Sven, > > I'm going to leave it the way it is for the time being, although you > could certainly change my mind. I am nowhere near being an expert > on Django models. > > In summary, using `models.ForeignKey` with the `related_name` > parameter gives us the ability to do the query we want in order to > retrieve the objects we want. > > More of my thinking on this is below. It's confused. And, if you'd > like to try to educate me, I'll certainly listen. > > Yes, I admit that I'm dragging my feet and going slow on this one. > I'm uneasy about the fact that what we've had until now is 180 > degrees in the opposite direction from the change we are > considering. > > But, after doing more reading and searching, I've also found this: > > https://docs.djangoproject.com/en/1.11/ref/models/fields/#django.db.models.ForeignKey.related_name > > That seems to suggest that `models.ForeignKey` when used with the > `related_name` parameter creates the backward relation from the > other model back to this one. Isn't that what we want? > > I also did the following search, and several of the top replies seem to > suggest that `ForeignKey` plus `related_name` does create that > reverse relation: > > https://www.ixquick.com/do/search?query=django%20foreignkey%20related_name > > For example, the above query led me to this: > >   related_name will be the attribute of the related object that >   allows you to go 'backwards' to the model with the foreign key >   on it. For example, if ModelA has a field like: model_b = >   ForeignKeyField(ModelB, related_name='model_as'), this would >   enable you to access the ModelA instances that are related to >   your ModelB instance by going model_b_instance.model_as.all(). >   Note that this is generally written with a plural for a Foreign >   Key, because a foreign key is a one to many relationship, and >   the many side of that equation is the model with the Foreign Key >   field declared on it. > >   The further explanation linked to in the docs is helpful. >   > > https://docs.djangoproject.com/en/1.10/topics/db/queries/#backwards-related-objects > >   related_query_name is for use in Django querysets. It allows you >   to filter on the reverse relationship of a foreign key related >   field. To continue our example - having a field on Model A like: >   model_b = ForeignKeyField(ModelB, related_query_name='model_a') >   would enable you to use model_a as a lookup parameter in a >   queryset, like: ModelB.objects.filter(model_a=whatever). It is >   more common to use a singular form for the related_query_name. >   As the docs say, it isn't necessary to specify both (or either >   of) related_name and related_query_name. Django has sensible >   defaults. > >   Ref: >   > > https://stackoverflow.com/questions/43132872/difference-between-related-name-and-related-query-name-attributes-in-django > > So, revisiting your original report: >   "I have an XSD with > >       <xs:element name="recipe"> >         <xs:complexType> >           <xs:sequence> > >             <xs:element name="title" > type="xs:string"/> > >             <xs:element name="categories"> >               <xs:complexType> >                 <xs:sequence> >                   <xs:element > name="category" type="xs:string" minOccurs="1" maxOccurs="unbounded"/> >                 </xs:sequence> >               </xs:complexType> >             </xs:element> >             .... >           </xs:sequence> >         </xs:complexType> >       </xs:element> > >   The Django models I get from that are > >     class Recipe(models.Model): >         title = models.CharField(max_length=1000, ) >         categories = models.ForeignKey( >             "CategoriesType", >            >  related_name="recipe_categories_categoriesType", >         ) >         .... > >     class CategoriesType(models.Model): >         category = models.CharField(max_length=1000, ) >         .... > > Django creates a one-to-many relationship from `CategoriesType` back > to `Recipe`. I think ... > > So, the question we need to ask is: given a recipe, can you find all > its categories? Right? The snippet above from Stackoverflow where > it says "ModelB.objects.filter(model_a=whatever)" suggests that you > can. In that example, ModelA would correspond to the Recipe and > ModelB would be the CategoriesType. > > I guess I'm arguing that the code we are currently generating really > is what we want. > > I apologize for being dense and slow on this. Although I wrote the > generateDS Django model generation code and actually did use Django > lightly in the distant past, I'm not a real Django user. > > And, thanks for pushing me on this. It really does need to be > straightened out one way or the other. > > Also, even if the current code *is* correct, it is certainly less > than intuitive and should be documented somehow. Oh, wait, it's a > relational database, so, of course it is not intuitive. > > Dave > On Mon, Oct 30, 2017 at 12:25:19PM +0100, Sven Prevrhal wrote: > >  Any further thoughts here Dave? > >  Cheers, > >  Sven > >  2017-10-24 13:43 GMT+02:00 Sven Prevrhal <sprev...@gmail.com>: > > > >   Dave- > >   Yes I believe your Model-A Model-B thoughts are correct for a > >   one-to-many when A has many B's. In a many-to-many situation > on DB level > >   one would use a mediation table, i.e. RecipeCategory with > foreign keys > >   to recipe and to category. In Django, this is modeled with the > >   ManyToMany qualifier. I don't know about your code but the > >   CategoriesType could play the role of the mediating table, > only that it > >   itself would not hold a char attribute but two foreign keys. I > believe > >   XML/XSD would make a many-to-many relationship explicit with > >   independent, i.e. not nested elements of Table A and Table B > and then > >   have a mediating element C_AB. This would be different from > the XSD I > >   had posted. Would generateDS Django readily translate this to > a > >   ManyToMany qualifier? Currently, I believe the code does not > implement > >   your Model A Model B thought for one-to-many relations, as the > >   foreignkey, like you said should indeed by with B. > >   Best regards > >   Sven > >   2017-10-23 23:55 GMT+02:00 Dave Kuhlman > <dkuhl...@davekuhlman.org>: > > > >    Sven, > > > >    I recommend that you do *not* read this email. The reason > is that I > >    have been confused about this issue before, and I am > (below) trying > >    to think it through and eliminate some of that confusion. > > > >    Maybe tomorrow I'll have a less twisted reply. > > > >    Let's see if we can get my head straight on this one. > > > >    A recipe can have a single "categories" and that > "categories" > >    element can contain multiple "category" elements. > > > >    Do we agree so far? > > > >    If so, the question is: How do we represent that in a > Django model? > > > >    In what is currently generated, the "Recipe" model has a > ForeignKey > >    to a "CategoriesType" model. This means that a record in > the > >    "Recipe" table (relation) can point to (refer to, be joined > with?) > >    multiple records in the "CategoriesType" table. > > > >    Which is what we want, right? Or am I twisting the fact > so that > >    they fit what I want to see? > > > >    Look at this snippet from the Django documentation (at > >    https://docs.djangoproject.com/en/1.11/topics/db/models/): > > > >        from django.db import models > > > >        class Musician(models.Model): > >            first_name = > models.CharField(max_length=50) > >            last_name = > models.CharField(max_length=50) > >            instrument = > models.CharField(max_length=100) > > > >        class Album(models.Model): > >            artist = > models.ForeignKey(Musician, > >    on_delete=models.CASCADE) > >            name = > models.CharField(max_length=100) > >            release_date = models.DateField() > >            num_stars = models.IntegerField() > > > >    Does the above mean that an "Album" can have multiple > musicians, that > >    is > >    references to multiple records in the "Musician" table? > Or, does it > >    mean that a musician can have multiple albums? > > > >    Here is another snippet from the same Web page: > > > >      Many-to-one relationships¶ > > > >      To define a many-to-one relationship, use > >    django.db.models.ForeignKey. You > >      use it just like any other Field type: by including > it as a > >    class attribute > >      of your model. > > > >      ForeignKey requires a positional argument: the class > to which > >    the model is > >      related. > > > >      For example, if a Car model has a Manufacturer â** > that is, a > >    Manufacturer > >      makes multiple cars but each Car only has one > Manufacturer â** > >    use the > >      following definitions: > > > >        from django.db import models > > > >        class Manufacturer(models.Model): > >          # ... > >          pass > > > >        class Car(models.Model): > >          manufacturer = > models.ForeignKey(Manufacturer, > >    on_delete=models.CASCADE) > >          # ... > > > >    In our case, we want a "Recipe" to have multiple instances > of > >    "CategoriesType". So, the should place the ForeignKey in > the > >    "CategoriesType" model. > > > >    So, perhaps the rule we should follow is: If you have > Model-A and > >    Model-B and if you want a Model-A to have multiple > instances of > >    Model-B, then put the ForeignKey in Model-B (referring to > Model-A). > > > >    What do you think? > > > >    It worries me that I seem to recall I've been confused > about this > >    before. > > > >    More on this tomorrow. > > > >    Dave > >    On Mon, Oct 23, 2017 at 08:33:36AM +0200, Sven Prevrhal > wrote: > >    > I have an XSD with > >    > > >    >  <xs:element name="recipe"> > >    >   <xs:complexType> > >    >    <xs:sequence> > >    > > >    >     <xs:element name="title" type="xs:string"/> > >    > > >    >     <xs:element name="categories"> > >    >      <xs:complexType> > >    >       <xs:sequence> > >    >        <xs:element name="category" > type="xs:string" > >    minOccurs="1" > >    > maxOccurs="unbounded"/> > >    >       </xs:sequence> > >    >      </xs:complexType> > >    >     </xs:element> > >    >     .... > >    >    </xs:sequence> > >    >   </xs:complexType> > >    >  </xs:element> > >    > > >    > The Django models I get from that are > >    > > >    > > >    > class Recipe(models.Model): > >    >   title = models.CharField(max_length=1000, ) > >    >   categories = models.ForeignKey( > >    >     "CategoriesType", > >    >    >  related_name="recipe_categories_categoriesType", > >    >   ) > >    >   .... > >    > > >    > and > >    > > >    > class CategoriesType(models.Model): > >    >   category = models.CharField(max_length=1000, ) > >    >   .... > >    > > >    > This seems wrong to me. I would have thought Category > gets a > >    ManyToManyField > >    > > >    > to Recipe. The way it comes out of generateDS it looks > like a > >    > CategoriesType has many Recipes. Or perhaps my XSD is > wrong? > >    > > >    > Cheers, > >    > Sven > > > >    > > >    > > ------------------------------------------------------------------------------ > >    > Check out the vibrant tech community on one of the > world's most > >    > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot > > > >    > _______________________________________________ > >    > generateds-users mailing list > >    > generateds-users@lists.sourceforge.net > >    > > https://lists.sourceforge.net/lists/listinfo/generateds-users > > > >    -- > > > >    Dave Kuhlman > >    http://www.davekuhlman.org > > -- > > Dave Kuhlman > http://www.davekuhlman.org -- Dave Kuhlman http://www.davekuhlman.org ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
