Unless I'm very confused, django will happily delete your related objects (since they don't have anything to relate to anymore). Many to many would be more problematic.
As far as creating a set of ports, you were stuck with that anyway, if I understand your original approach correctly. Even if your model had N red port slots and M green port slots, with flags as to whether this product has that port, (each product is an instance of "A", no?), you have to fill in the flag and any individual data (port address, for example) when you create the instance for a product. The only difference with the many to one is that you call the port constructor, passing the product instance, and after the fields are filled, you call the save method. In turn, you get enumeration of the set of ports that you actually have in this product for free from the framework, rather than having to write code to skip the ports not present in this product. Probably not useful in your case, but you can adjust the set of ports on a product "later" with the foreign key scheme. If, on the other hand, you were going to make a model per product type, forget all that I said. On Mon, Dec 7, 2009 at 11:56 AM, Daniel Goertzen <daniel.goert...@gmail.com> wrote: > Thanks for the reply Bill. The problem I had with that approach is that > after creating the product I have to worry about creating red and green > ports. Likewise, upon deletion, I have to mop up the ports. Looking > through the documentation, I did not find a way to bury this behavior in the > Model. > Hmm, abstract base class for the ports is an interesting idea. Could be > useful at template time. > Dan. > > On Mon, Dec 7, 2009 at 10:07 AM, Bill Freeman <ke1g...@gmail.com> wrote: >> >> I'm not clear on what you need to store, so I'll assume that you have >> individual >> data to store for each port of each type, and it is unrelated to data >> stored for >> another instance of the same or a different product. >> >> What comes to mind is that there is a "Product" model and a "Port" model >> (or if >> red and green ports carry different fields, both a "RedPort" and a >> "GreenPort" >> model). Ports have a foreign key relationship on Products. Now an >> assortment >> of Port instances can be assigned to a Product instance. Django will >> created >> an accessor (or accessors) on the Product model for obtaining a query set >> of >> the Port instances associated with a given Product instance. (If you want >> separate RedPort and GreenPort models, but they share a lot of behaviours >> and/or fields, you may want to look at Django's abstract base class >> mechanism, >> but it takes a bit to get right, in my experience.) >> >> >> On Mon, Dec 7, 2009 at 10:12 AM, Dan <daniel.goert...@gmail.com> wrote: >> > I am relatively new to django and relational databases, and need some >> > Model advice. >> > >> > I have a family of network products each with a different combination >> > of ports.. I will call them red ports and green ports. For example, >> > product A will have its own Model and could have 2 red ports and 1 >> > green port. Product B is similar, but has only 3 green ports. >> > My current approach is to use an abstract base Model, and then create >> > Models for products A and B that contain all needed fields, for >> > example: >> > >> > class A(basemodel): >> > Port1_redfield1 = ... >> > Port1_redfield2 = ... >> > ... >> > Port2_redfield1 = ... >> > Port2_redfield2 = ... >> > ... >> > >> > >> > Yuck, not very DRY at all. I also tried to create a red port Model >> > and green port Model and use one to one fields to connect them to >> > products. The problem with this is that I could not figure out how to >> > encapsulate the ports; I always had to worry about creating, linking >> > and deleting port objects when dealing with products. Not acceptable. >> > >> > I also thought about other tricks like generating my models.py file >> > from a generator program, and dynamic insertion of attributes into >> > existing classes. I really would rather not go there. >> > >> > So, my question: Is there a nice DRY way to get the kind of >> > structured composition that I want? >> > >> > Side question: Is there another python ORM that could address my need >> > better? >> > >> > Thanks, >> > Dan. >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups "Django users" group. >> > To post to this group, send email to django-us...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > django-users+unsubscr...@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/django-users?hl=en. >> > >> > >> > >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > > > > -- > Daniel Goertzen > ----------------- > d...@networkintegritysystems.com (work) > daniel.goert...@gmail.com (home) > ----------------- > 1 204 272 6149 (home/office) > 1 204 470 8360 (mobile) > ----------------- > > > > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
