Hi Marten,
Sorry for the late response, it's been a busy week. Thanks for working on this, I'll try to have a look at your branch this weekend.
In the meantime I'll leave some comments below.
> On Feb 12, 2015, at 22:43, Marten Kenbeek <
marte...@gmail.com> wrote:
>
> Current status:
> • Models in general seem to be working.
> • Trying to override a concrete (or explicitly locked) field with an abstract field will keep the concrete field, but not raise any errors. This occurs when inheriting from (AbstractBase, ConcreteBase).
> • I might still change this to raise an error, it migth cause a few headaches when fields don't appear while they're first in the mro.
This should definitely be an error. We recently added checks so two concrete parents can't have clashing fields, this is similar.
> • Trying to override field.attname (e.g. foo_id) will fail checks unless you explicitly set foo = None.
> • Trying to override an abstract field with a reverse relation will fail checks unless you explicitly set foo = None.
That's good.
> What is still needed:
> • ? More extensive model tests. During development a few more bugs popped up. I've written tests for them, but there might be some more.
> • Explicit migration tests. Existing migration tests pass, but don't include the new scenario's.
> • Documentation.
> My WIP branch can be found at
https://github.com/knbk/django/compare/ticket_24305.
>
> Op dinsdag 10 februari 2015 14:36:53 UTC+1 schreef Marten Kenbeek:
> Hi Aron,
>
> With option 3, this would work:
>
> class Cousin(models.Model):
> child = models.ForeignKey(Child, allow_override=True)
>
> but it would raise an error without `allow_override`.
>
> I think my question really is: should we treat reverse relations as first-class fields, or not? If we do, 1) would be the logical choice but can cause problems. 3) would deal with those problems in a way and still allow a relation field from another model to override a local field. If we don't, that kind of implies 2). Removing the field with `None` would implicitly allow a reverse relation to take its place, but that reverse relation in and of itself would not be allowed to override any abstract fields.
>
> This is just an example. In real code this would more likely happen with an explicit `related_name`. Renaming the related name and living with an unused `cousin_set` attribute is the current solution, but with this feature proposal it would be nice to also have a way to override the inherited field and use it for a reverse relation instead.
>
>
> Op dinsdag 10 februari 2015 02:28:58 UTC+1 schreef Aron Podrigal:
> Why should this be treated differently than the general behavior when realted_names clash when you have more than one foreign key to the same model? So as one would normally do
> set the related_name explicitly to some other value.
> setting the field to None is just the way of removing a field and has nothing more special related to the auto created reverse field descriptor.
> about option 3 I didn't quite understand. can you explain a bit more?
+1 to what Aron said.
>
> On Monday, February 9, 2015 at 4:25:22 PM UTC-5, Marten Kenbeek wrote:
> I'd like some additional opinions on the following:
>
> Say you have the following classes:
>
> class Parent(models.Model):
> cousin_set = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
>
> class Child(Parent):
> pass
>
> class Cousin(models.Model):
> child = models.ForeignKey(Child)
>
> Obviously, the `cousin_set` field inherited from `Parent` clashes with the reverse relation from `Cousin`.
>
> I can see the following options:
> 1) Allow the reverse object descriptor to overwrite the field.
No this would be very confusing.
> 2) Only allow the reverse object descriptor to overwrite the field if it is explicitly set to None on the target model.
Yes but as Aron pointed out we aren't specifically "allowing" the descriptor to override the field, it's just that the field was already removed (through None) so the reverse descriptor isn't clashing with anything.
> 3) Only allow the reverse object descriptor to overwrite the field if the foreignkey/m2m/o2o field itself has a flag set to explicitly override.
Let's not do that, it's clunky, I also don't like the locking mechanism mentioned above.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/6e3e363f-bdc6-410b-b145-76085051e053%40googlegroups.com.