thanks for the references, I missed that part. it does look similar but not exactly what I had in mind... what this means is that I can now have an abstract model which will be a base model to all models who can have an address. this abstract model will define the different fields which makes an address, but won't create a table for them. now, every model who wants to have an address will extend that abstract model and will automatically gain these fields.
the difference is that all of fields and methods (which will be defined on those fields) will be part of the extending model instead of it owning an address object holding the data/functionality. I will give it a try though. thanks again. On Nov 8, 8:24 am, Jani Tiainen <rede...@gmail.com> wrote: > On Friday 05 November 2010 22:53:06 nitm wrote: > > > > > > > Hi, > > > Is there a way to combine a set of fields I have in a model class into > > a different class without it having it's own separate table? > > An example: > > > I want to implement the user profile model class, and in it I would > > like to have the address of the user. > > The address is group of fields (city, street, number, zip code) and > > so, instead of having this: > > > class UserProfile(models.Model): > > city = models.ForeignKey(City) > > street = models.CharField(max_length=200) > > number = models.IntegerField() > > zip = models.IntegerField() > > > .... > > > I would like to do something similar to: > > class Address: > > city = models.ForeignKey(City) > > street = models.CharField(max_length=200) > > number = models.IntegerField() > > zip = models.IntegerField() > > > class UserProfile(models.Model): > > address = ??? > > > .... > > > It just seems more comfortable if I can group these fields into one > > class and add methods to it (for example different string > > representations) but I would still like the actual fields to be part > > of the user profile table and not a new table just for address (since > > it's a one to one relationship). > > > Is something like that possible ? > > Thanks. > > That can be achieved very easily by using abstract model(s) and inheritance. > Though it's not that intuitive but looks similiar. Also you need to be very > careful about reverse relations. > > See more > at:http://docs.djangoproject.com/en/1.2/topics/db/models/#abstract-base-... > > http://docs.djangoproject.com/en/1.2/topics/db/models/#be-careful-with- > related-name > > -- > > Jani Tiainen -- 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.
