On Saturday 09 January 2016 00:15:32 Markus Holtermann wrote:
> That's a nice one, Simon.
>
Yep.
[Simon said: 1: error out, 2: take model from child's app; 3: take model from
abstract parent's app]
> tl;dr: I favor 2; am OK with 1 but against 3.
>
But here I no longer agree.
> I was favoring 1) as well. But then thought that app relative relationships
> actually make sense and the current behavior adds a nice new API feature.
> This way a 3rd party app can provide an abstract model and require you to
> implement 2 models: the inheriting and the referred with a specific name.
>
This makes little sense to me. It makes sense for an abstract model to require
the concrete model to have some FK-like attribute -- you do that by using said
attribute in the abstract model's methods; looking for a definition of another
model specifically is forcing implementation details.
Also, there have been sevaral discussions in the past about allowing
inheritors to override an abstract model's fields; that feature can be useful,
but introducing a vaguely-specified, very partial implementation of it as an
afterthought to a different feature does not strike me as a good way to go.
I don't like option 1 either -- it is slightly backwards-incompatible, and
reeks of "action at a distance" (I am not allowed to name a model in app2
"Refered" because a model by that name exists in app1 and is referred to by a
model in app1, which I happen to inherit in app2...).
So, I say, go for option 3. A field defined in a model in app1 takes app-
relative references in app1.
My 2 cents,
Shai.
