On Mon, 2006-08-07 at 09:26 -0700, Bjørn Stabell wrote:
> Okay, I've got one more question. If we're not going to support
> querying for an object's real type, it becomes quite cumbersome to do
> anything polymorphically, which kind-of is the point of
> object-orientation.
This stuff is hard not because we are not very clever, but because it is
quite possibly fundamentally hard. There is a famous comment from Bjarne
Stroustrup where he mentioned that AT&T (his employer) had tried very
hard to map object models onto relation databases and had come to the
conclusion it just wasn't possible to do. With pedigree like that laying
the groundwork, I don't mind making a few compromises in order to make
some things easy and all things somehow possible.
One of the compromises we are making is deciding to make sharing common
stuff (one benefit/point of inheritance) trivially easy, possibly at the
slight expense of other things. Working with the most-derived objects is
transparent. Working from the other end of the stack, with the base
classes and trying to use polymorphism everywhere is going to be a bit
more painful. We tried not to make this sacrifice, but, as pointed out
earlier in this thread and in other threads, all other designs had their
trade-offs as well.
> For example, to use the same URI spec & view for all the subtypes.
>
> OPTION 1: lots of if-then-else's
>
> def detail_view(id):
> place = Place.objects.get(id)
> if place.isinstance(Place): model_name = 'Place'
> elif place.isinstance(Restaurant): model_name = 'Restaurant'
> ...
> return render_to_response("templates/place_%s.html" % model_name,
> place)
This is why Russell was talking about the a narrow()-like function
earlier. It exists in CORBA to make this type of thing easier. You can
see our conclusion on that earlier in this very thread.
Also, if you are going to need to do this sort of thing frequently, you
can build a small app much like content-type that maps (model name, pk)
to "most derived type". That would act precisely like a discriminator
column (because it *is* one) and you could be able to work smoothly with
polymorphic objects. The reason we didn't put this in the main design by
default is because we are tending to avoid auxilliary tables in core
parts of Django (note that ContentTypes is an optional model, for
example). The database maintenance and requirements to keep another
table in sync is a consideration.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
