Re: model design problem
Or there's overriding the metaclass... On Mon, Dec 7, 2009 at 12:39 PM, Bill Freemanwrote: > Hmmm. Probably just as ugly, and untested, but: > > class A(basemodel): > for o in range(MAXNUMREDPORTS): > for i in (1,2): > locals()["Port%d_redfield%d" % (o+1, i)] = models.FloatField() > ... > > On Mon, Dec 7, 2009 at 12:10 PM, Daniel Goertzen > wrote: >> Okay, I explored model generation a bit and found an approach that wasn't >> too offensive. For those that are trying to solve the same problem that I >> am, here is what I came up with: >> >> def red_port(prefix): >> return """ >> %(prefix)sredfield1 = models.FloatField() >> %(prefix)sredfield2 = models.FloatField() >> """ % {'prefix':prefix} >> class A(basemodel): >> exec red_port("Port1_") >> exec red_port("Port2_") >> ... >> >> ...which yields sql something like... >> CREATE TABLE `A` ( >> `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, >> ... >> `Port1_redfield1` double precision, >> `Port1_redfield2` double precision, >> `Port2_redfield1` double precision, >> `Port2_redfield2` double precision, >> ); >> >> >> I feel DRY again, and only a little bit dirty. :) >> Dan. >> >> On Mon, Dec 7, 2009 at 9:12 AM, Dan 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. >> >> >> -- >> 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.
Re: model design problem
Hmmm. Probably just as ugly, and untested, but: class A(basemodel): for o in range(MAXNUMREDPORTS): for i in (1,2): locals()["Port%d_redfield%d" % (o+1, i)] = models.FloatField() ... On Mon, Dec 7, 2009 at 12:10 PM, Daniel Goertzenwrote: > Okay, I explored model generation a bit and found an approach that wasn't > too offensive. For those that are trying to solve the same problem that I > am, here is what I came up with: > > def red_port(prefix): > return """ > %(prefix)sredfield1 = models.FloatField() > %(prefix)sredfield2 = models.FloatField() > """ % {'prefix':prefix} > class A(basemodel): > exec red_port("Port1_") > exec red_port("Port2_") > ... > > ...which yields sql something like... > CREATE TABLE `A` ( > `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, > ... > `Port1_redfield1` double precision, > `Port1_redfield2` double precision, > `Port2_redfield1` double precision, > `Port2_redfield2` double precision, > ); > > > I feel DRY again, and only a little bit dirty. :) > Dan. > > On Mon, Dec 7, 2009 at 9:12 AM, Dan 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. > > > -- > 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.
Re: model design problem
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 Goertzenwrote: > 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 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 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 >>
Re: model design problem
On Dec 7, 8:56 am, Daniel Goertzenwrote: > 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. I think you misunderstand - I think the suggestion is, and I agree with it, is to have your specific Products represented as instances in the database, not as code objects. If the products are similar enough - have one "Product" model with fields like, name, modelnumber etc Then have one "Port" Model, that might have fields like "color" etc Then you create an instance of a product and related port instances in the database, not in model code. Yes you have to define the unique combinations, but you have to do this once somewhere. Any place you need to refer to that product model, you use a foreignkey to that product _instance_ in the database. -Preston > > 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 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 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 > groups.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 > groups.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
Re: model design problem
Okay, I explored model generation a bit and found an approach that wasn't too offensive. For those that are trying to solve the same problem that I am, here is what I came up with: def red_port(prefix): return """ %(prefix)sredfield1 = models.FloatField() %(prefix)sredfield2 = models.FloatField() """ % {'prefix':prefix} class A(basemodel): exec red_port("Port1_") exec red_port("Port2_") ... ...which yields sql something like... CREATE TABLE `A` ( `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, ... `Port1_redfield1` double precision, `Port1_redfield2` double precision, `Port2_redfield1` double precision, `Port2_redfield2` double precision, ); I feel DRY again, and only a little bit dirty. :) Dan. On Mon, Dec 7, 2009 at 9:12 AM, Danwrote: > 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. -- 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.
Re: model design problem
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 Freemanwrote: > 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 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.
Re: model design problem
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, Danwrote: > 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.
Re: model design problem
Each port would have about a half-dozen fields, and different port types are totally different from one another. I won't be querying port fields. I've thought about your JSON field trick before, but not with the nice wrapper methods. Good idea, thanks! The solution does have flaws, but if nothing better comes up I might just go this way. Thanks again, Dan. On Mon, Dec 7, 2009 at 9:20 AM, Shawn Milochikwrote: > What kind of information will the database have to store about the ports > themselves? > > How will you need to be able to filter querysets by information in the port > fields, if at all? > > I'm going to throw this one solution out there, but depending on your needs > it may not fit: > > Create a red_ports column and a green_ports column in your model. Each one > will contain serialized JSON. You can just dump a Python dictionary into > those fields with simplejson.dumps, and retrieve the data with > simplejson.loads. Then, you add methods to your model which you can use in > the views that deal with the model. > > > > > > Here are a couple of lines of code from one of my models. I'm storing the > hashes of old passwords to prevent people from re-using passwords. > > #field definition in model > prev_passwords = models.TextField(default = '{}') > > I then get and set the values like this: > >def _get_prev_passwords(self): >return simplejson.loads(self.prev_passwords) > >def _set_prev_passwords(self, pw_dict): >self.prev_passwords = simplejson.dumps(pw_dict) > >previous_passwords = property(_get_prev_passwords, _set_prev_passwords) > > This way, my model's .previous_passwords attribute is available in my > views, and the serialization is transparent. > > > > > So, your Python dictionaries can contain all kinds of data about the red > and green ports, and contain entries for any number of ports. Your models > remain clean. > The biggest flaw in this method is that, if you need to select a set of > products based on an attribute of a port, you'll have to jump through hoops > to make it happen. > > Shawn > > > -- > > 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.
Re: model design problem
What kind of information will the database have to store about the ports themselves? How will you need to be able to filter querysets by information in the port fields, if at all? I'm going to throw this one solution out there, but depending on your needs it may not fit: Create a red_ports column and a green_ports column in your model. Each one will contain serialized JSON. You can just dump a Python dictionary into those fields with simplejson.dumps, and retrieve the data with simplejson.loads. Then, you add methods to your model which you can use in the views that deal with the model. Here are a couple of lines of code from one of my models. I'm storing the hashes of old passwords to prevent people from re-using passwords. #field definition in model prev_passwords = models.TextField(default = '{}') I then get and set the values like this: def _get_prev_passwords(self): return simplejson.loads(self.prev_passwords) def _set_prev_passwords(self, pw_dict): self.prev_passwords = simplejson.dumps(pw_dict) previous_passwords = property(_get_prev_passwords, _set_prev_passwords) This way, my model's .previous_passwords attribute is available in my views, and the serialization is transparent. So, your Python dictionaries can contain all kinds of data about the red and green ports, and contain entries for any number of ports. Your models remain clean. The biggest flaw in this method is that, if you need to select a set of products based on an attribute of a port, you'll have to jump through hoops to make it happen. Shawn -- 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.
model design problem
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.
Re: Model design problem ? (double ForeignKey)
>>responsable = models.ForeignKey('Personne', ...) >> >> if you need to forward-reference a model that hasn't yet been >> defined. > > thanks for the anwser. > I dont saw this particular sentence. The magic is in the phrase "If you need to create a relationship on a model that has not yet been defined, you can use the name of the model [a string], rather than the model object itself" > But now I have this message: > directory.unite: Reverse query name for field 'responsable' clashes > with field 'Personne.unite'. Add a related_name argument to the > definition for 'responsable'. > > so I add a stuff like this > > class Unite(models.Model): > responsable = models.ForeignKey('Personne', verbose_name='The > Chief', blank=True, related_name='chef') > ... > > class Personne(models.Model): > unite = models.ForeignKey(Unite,null=True) > > > > but I'am not sure to understand: this related_name='chef' add a > attribute .chef to my Personne model ? or what ? When you add a foreign-key to your model, the referenced model gets a psedudo-attribute, usually called _set which is the set of s that have this attribute. By adding the related_name, you provide a way to reference the Units for which a Personne is responsible. Thus, it might make it clearer to use something like related_name='managed_units' which allows you to iterate over the units a person manages: for person in Personne.objects.select_related().all(): if person.managed_units: print person, 'manages the following units:' for unit in p.managed_units: print '-', unit The details of this are found at http://www.djangoproject.com/documentation/db-api/#backward -tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Model design problem ? (double ForeignKey)
> >responsable = models.ForeignKey('Personne', ...) > > if you need to forward-reference a model that hasn't yet been > defined. thanks for the anwser. I dont saw this particular sentence. But now I have this message: directory.unite: Reverse query name for field 'responsable' clashes with field 'Personne.unite'. Add a related_name argument to the definition for 'responsable'. so I add a stuff like this class Unite(models.Model): responsable = models.ForeignKey('Personne', verbose_name='The Chief', blank=True, related_name='chef') ... class Personne(models.Model): unite = models.ForeignKey(Unite,null=True) but I'am not sure to understand: this related_name='chef' add a attribute .chef to my Personne model ? or what ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Model design problem ? (double ForeignKey)
> I like to do something like that in a app models.py: > > > class Unite(models.Model): > responsable = models.ForeignKey(Personne, verbose_name='The > Chief', blank=True) > ... > > class Personne(models.Model): > unite = models.ForeignKey(Unite,null=True) > > > > And I have this error message in devel server: > annuaire.directory: name 'Personne' is not defined According to http://www.djangoproject.com/documentation/model-api/#many-to-one-relationships you want responsable = models.ForeignKey('Personne', ...) if you need to forward-reference a model that hasn't yet been defined. -tkc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Model design problem ? (double ForeignKey)
I like to do something like that in a app models.py: class Unite(models.Model): responsable = models.ForeignKey(Personne, verbose_name='The Chief', blank=True) ... class Personne(models.Model): unite = models.ForeignKey(Unite,null=True) And I have this error message in devel server: annuaire.directory: name 'Personne' is not defined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---