Thanks so much for the tips, Favo.  There are some points that are
unclear to me, so I hope you don't mind if I ask a few questions.

On 12/24/06, favo <[EMAIL PROTECTED]> wrote:

1. as you said, use OneToOne field

                        class Place(models.Model):
                                name = models.CharField(maxlength=50)
                        
                        class Restaurant(models.Model):
                                place = models.ForeignKey(Place)
                                type_of_food = models.CharField(maxlength=50)

Should that be a `OneToOneField` instead of a `ForeignKey`?

2. use OO inheritance, current django support inheritance model --
inheritance all parent fields to child.
                        class Place(models.Model):
                                name = models.CharField(maxlength=50)
                        
                        class Restaurant(Place):
                                type_of_food = models.CharField(maxlength=50)
                        # fix default manager
                        _default_manager = Model.Manager()
                        _default_manager.model = Restaurant
                        Restaurant._default_manager= Restaurant.objects =
                        _default_manager

Where does that default manager code go?  It's not in the class
definition, is it?

In fact, do you happen to have a more complete piece of code that uses
this approach and could be shared with the list?

> 1. If I ask for a list Places matching certain criteria, then Hotels,
> Restaurants, and basic Places matching the criteria should all be
> returned.

In second way need sync the child field with the base instance.

I don't understand your response here.  Can you give a code snippet?

> 3. Restaurants and Hotels should be their own independent entities.  If
> there is some crazy stuff going on with foreign keys and multiple
> tables behind the scenes, it should stay behind the scenes as an
> implementation detail.  So if I delete a Hotel object, it should
> automatically delete the associated Place object if there is such a
> thing in the implementation.

In both way you have to do it yourself, but you could use signals have
you to do it automatically.

Can you give an example of this?  I'm not familiar with signals.


Again, thanks a lot for taking the time to respond.

Aaron

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

Reply via email to