You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, this comment explains our position on the matter:
You'd think relating to element would be, well, elemental.
But it turns out not to be. Instead, we have literal and ethereal versions
of our products and services as subclasses, and then get down with one another directly.
This is an interesting concept, but there's obviously no way to enforce the underlying relationship. It also makes it difficult to instantiate a RealThing that doesn't belong to a subclass - are we taking the position that every RealThing is a sublcass (ie, a Product or Service or Ingredient or...?)
Even if this is so, we can use django-model-utils to ensure that we get a clean drill down. We'll need to use a join either way, so why not have one field?
The text was updated successfully, but these errors were encountered:
Currently, this comment explains our position on the matter:
You'd think relating to element would be, well, elemental.
But it turns out not to be. Instead, we have literal and ethereal versions
of our products and services as subclasses, and then get down with one another directly.
This is an interesting concept, but there's obviously no way to enforce the underlying relationship. It also makes it difficult to instantiate a RealThing that doesn't belong to a subclass - are we taking the position that every RealThing is a sublcass (ie, a Product or Service or Ingredient or...?)
Even if this is so, we can use django-model-utils to ensure that we get a clean drill down. We'll need to use a join either way, so why not have one field?
The text was updated successfully, but these errors were encountered: