Jacob Kaplan-Moss wrote:

> 1. Modeling parent relations in SQL: #3 seems to make the most sense 
> for me -- I can't think of a case in a one2one where the child id  would
> need to differ from the parent id.  Also::
> 
>     CREATE TABLE "myapp_restaurant" (
>         "id" integer NOT NULL PRIMARY KEY REFERENCES  "myapp_places"
> ("id"),
>         "description" text NOT NULL
>     );
> 
> works just fine (at least in Postgres); I'd suggest that SQL  relations
> be used explicitly here.

Agree here. There is absolutely no meaning in a subtyping relationship
in which the members of the supertype do not share an identity domain.

> 2. Modeling joins in SQL / lookup API: my general take on this is  "make
> it explicit".  If I ask for places, give me a list of places  and don't
> bother looking up restaurants.  So::   ``place_instance.description``
> should raise an ``AttributeError``  regardless if weather or not it is
> actually a restaurant.
> 
> However, there means there should be a way, given a Place, to get a 
> Restaurant; I would suggest::
> 
>     >>> p = Place.objects.get(pk=1)
>         >>> r = Restaurant(p)
>         >>> i = ItalianRestaurant(p)    # or ...(r)
> 
> (I suggest this syntax since it looks like exactly like casting -- 
> ``foo = int(bar)``).

This is horrible. If something is a restaurant, it should always act
like a restaurant. It should not depend on interrogating the object "Are
you a restaurant?" - this would become as tedious as dynamic_cast in
C++. Think about a method that is overridden in Restaurant. Does it make
any sense at all for its behaviour to depend on whether you have
explicitly cast it to the correct type? This completely breaks OO - very
similar to object slicing in C++. Not something to duplicate.

If a base class has subclasses, all queries on the base class need to be
joined to the tables representing all subclasses. Then the results can
be instantiated into the correct type. Maybe the .values() query can
just return the base class values if the joins are scaring people.

Please don't rely on phrases like "explicit is better than implicit" to
make your decisions for you - if we did that, everyone would be using ASM.

Reply via email to