On 17/01/2012 4:05am, Bill Freeman wrote:
Two thoughts:
1. Have both a one to one and a one to many onto the same children.
There's no reason that the current child can't be in both
relationships, or you could keep them disjoint by "moving" the old
current child to the collection when it id displaced by a new child.
I like this. Perhaps in the model there could be a 1:1 field with
choices=<children in the 1:n set> ??? I guess I'll need to experiment.
My existing schema has 1:n between parent and children and the children
have a 1:1 between themselves forming links in a chain as you suggest
below.
2. Have a many to many on self in the child (set) or a one to one (or
just foreign key on self (list) so that the current child allows
access to the history children.
Or am I misunderstanding the problem.
Not at all. But I think I'm getting it. If your #1 thought doesn't work
I'll try and filter out all children except for the current one and
then, in the form for the only visible child, find a way to navigate
forward to the not-yet-current one and backward to the immediate
predecessor.
Thanks Bill
Mike
Bill
On 1/16/12, Mike Dewhirst<mi...@dewhirst.com.au> wrote:
On 16/01/2012 5:19pm, Bill Beal wrote:
Why not have a child model that differs from the one-to-one child model
in that the parent key is now a foreign key to the parent? When another
child needs to replace the current one in the one-to-one relationship,
move the child to the second table where there is a many-to-one
relationship to the parent, then modify the one-to-one child record. If
necessary, duplicate the current one-to-one record in the many-to-one
table. Does this make sense?
I understand what you mean but it feels a bit yukky. Thinking about it
some more maybe I need a 'hidden' field which gets updated on saving
based on the existence of a more modern child.
Dunno.
Thanks
Mike
Bill Beal
On Mon, Jan 16, 2012 at 12:55 AM, Mike Dewhirst<mi...@dewhirst.com.au
<mailto:mi...@dewhirst.com.au>> wrote:
I need a one-to-many to behave like a one-to-one.
The parent instance of my model can only ever have one current child
instance of another model. Multiple child instances have to exist
and be kept for the historical record.
The main benefit of one-to-one relationships is that they can be
mapped together (in the Admin) as an extension of the parent.
In a view I suppose I can use a manager to filter the children into
a pseudo-one-to-one thingy but how do I do this in the Admin?
Maybe sort them into date order and only show one? Is there a better
way?
Thanks for any help
Mike
--
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
<mailto:django-users@googlegroups.com>.
To unsubscribe from this group, send email to
django-users+unsubscribe@__googlegroups.com
<mailto:django-users%2bunsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/__group/django-users?hl=en
<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-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.
--
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
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-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.
