Re: model design problem

2009-12-07 Thread Bill Freeman
Or there's overriding the metaclass...

On Mon, Dec 7, 2009 at 12:39 PM, Bill Freeman  wrote:
> 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

2009-12-07 Thread Bill Freeman
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

2009-12-07 Thread Bill Freeman
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
 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  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

2009-12-07 Thread Preston Holmes


On Dec 7, 8:56 am, Daniel Goertzen  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.

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

2009-12-07 Thread Daniel Goertzen
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.




Re: model design problem

2009-12-07 Thread Daniel Goertzen
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
> 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

2009-12-07 Thread Bill Freeman
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.




Re: model design problem

2009-12-07 Thread Daniel Goertzen
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 Milochik  wrote:

> 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

2009-12-07 Thread Shawn Milochik
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

2009-12-07 Thread Dan
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)

2007-07-25 Thread Tim Chase

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

2007-07-25 Thread Master.h2zu


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

2007-07-25 Thread Tim Chase

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

2007-07-25 Thread Master.h2zu

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