If I'll do something like:
class Car(models.Model):
name = models.CharField(max_length=100)
parts = models.ManyToManyField('Part', through = 'PartsInCar')
class Part(models.Model):
name = models.CharField(max_length=100)
class PartsInCar(models.Model):
car = models.ForeignKey('Car')
part = models.ForeignKey('Part')
amount = models.IntegerField()
Whats the advantage of doing it 'through' if I can just make it a new
model? Or am I completely wrong about everything again? :)
(Sorry for the double post)
W dniu piątek, 6 lipca 2012 19:14:53 UTC+2 użytkownik Soviet napisał:
>
> Thanks, but damn, isn't that overly complicated (for me). Using through
> looks like a easier way, but then I have to add Wheel four times and can't
> just type '4' in some field, since I don't need it to exist in database
> four time, just an information that there are four wheels.
>
> W dniu piątek, 6 lipca 2012 16:43:27 UTC+2 użytkownik Tomas Neme napisał:
>>
>> > I don't understand. It's the same wheel added four times, not four
>> > different wheels.
>>
>> I guess you could implement it either way. The thing is that doing it
>> this way would become complicated at the time you need to define what
>> is attached where. For Lego pieces, I'd do this:
>>
>> class LegoType(Model) has a description, maybe a picture, and it's
>> behavior
>>
>> model LegoPiece has a ForeignKey(LegoType), a ManyToMany to other
>> LegoPieces (the ones it's connected to).
>>
>> You'd have one LegoType = wheel, and four LegoPiece who's type would
>> be wheel. When you defined the Type you'd need a way to link each
>> model to specific python code that controlled how many pieces it can
>> connect to, and how, but that's a song for another day.
>>
>> Then you do LegoPiece.objects.filter(type__name="wheel").count(), and
>> voila, you have how many wheels you have.
>>
>> You COULD have enough knowing the amount of pieces of each kind you
>> have, you'd be modeling something similar to an inventory, but
>> defining connections in that context would be unnecessarily
>> complicated, since you'd not only have to count how many pieces you
>> have of each type, but when you connect one to another, *which one*
>> are you connecting? one that's free, or one that's connected to
>> another one? How would you model the connections? Say one brick can
>> connect to as many as 8 other pieces, 4 on each side, say you have 3
>> bricks, so you know you can't have more than 24 connecctions, but..
>> how do you differentiate between A--B C--D--E and A--B--C--D or.. I
>> don't know how to draw it, but D--A--B D--A--C (A is connected to D on
>> one side, and to B and C both on the other).
>>
>> It might be that you can model your needs this way, but AFAICS, it'd
>> be a lot harder to follow things and keep things consistent in an
>> Object Oriented way.
>>
>> --
>> "The whole of Japan is pure invention. There is no such country, there
>> are
>> no such people" --Oscar Wilde
>>
>> |_|0|_|
>> |_|_|0|
>> |0|0|0|
>>
>> (\__/)
>> (='.'=)This is Bunny. Copy and paste bunny
>> (")_(") to help him gain world domination.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/ifxvdi0WJNUJ.
To post to this group, send email to django-users@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.
