Allowing Reverse, Single Inlines in Admin

[Tyler Kocheran]

Presently, there's not a way without altering models to be able to have inline models if dependencies are declared on the "owning" class. Allow me to explain with code:

class Person(models.Model):

    address = models.OneToOneField("Address")

class Monument(models.Model): 

    address = models.OneToOneField("Address")

class Sighting(models.Model):

    address = models.OneToOneField("Address")

class Address(models.Model):

    name = models.CharField(...)

    street_address = models.CharField(...)

The goal with this code is that a `Person` owns an `Address` like a `Monument` owns an `Address` like a `Sighting` owns an `Address`. There's really no reason for an `Address` to know of itself what it is owned by, it could be owned by multiple different objects. The lookup needs to happen from the owner.

When attempting to make inlines for these types of relations, an error is thrown:

class AddressInline(admin.TabularInline):

    model = Address

    fields = ('street_address',)

class SightingAdmin(admin.ModelAdmin):

    inlines = (AddressInline,)

 Here's the error which is thrown by a similar real example: http://pastebin.com/rQreWCwY

IMHO, inlines should work regardless of which side the relationship is declared on. Can I submit this for a feature request? 

[ptone]

On Friday, March 30, 2012 11:44:29 AM UTC-7, Tyler Kocheran wrote:

 There's really no reason for an `Address` to know of itself what it is owned by, it could be owned by multiple different objects.

Not if you are using a OneToOneField...

I think you are just looking for a FK to an address model on each of your other models.

-Preston

[Tyler Kocheran]

I mean "multiple types of objects." Basically, in the db, it looks a bit like this:

create table address(id int primary key auto increment, name text, address text);

create table person(id int primary key auto increment, first_name varchar(30),

        last_name varchar(30), address_id int foreign key references "address"("id"));

create table sighting(id int primary key auto increment, name varchar(30),

        address_id int foreign key references "address"("id"));

What I mean to say is that "Address" doesn't need to know in the database that its owned by something else, that notion of ownership is indicated elsewhere. Sure, in Django, you could climb "Address.person" to get to the owning person. In any case, that's somewhat beyond the point.

The real point is that I shouldn't be getting errors if I want to have a OneToOneField inline of an Address on a Person. No matter what side the relation is declared on, inlines should just work™. Maybe it's not the best idea for a data model, but if a user has this requirement, Django should be flexible enough to meet it, and I do think it's a good idea.

Thanks,

 - TK

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/1qyvaXw39QsJ.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[ptone]

On Friday, March 30, 2012 1:58:08 PM UTC-7, Tyler Kocheran wrote:

The real point is that I shouldn't be getting errors if I want to have a OneToOneField inline of an Address on a Person. No matter what side the relation is declared on, inlines should just work™. Maybe it's not the best idea for a data model, but if a user has this requirement, Django should be flexible enough to meet it, and I do think it's a good idea.

Now that I understand - I agree.  Looking at this briefly - it would be a matter of making the notion of "parent_model" in inlineformset_factory be valid on either side of the OneToOne.

This would be some form of letting SingleRelatedObjectDescriptor be as valid as a fk in django.forms.models._get_foreign_key()

This actually has very timely bearing on the auth discussion believe it or not...

-Preston

[Tyler Kocheran]

YUSS. Yeah, it's just been kind of frustrating trying to get this to work lately. I designed a whole model set, then realized that it won't work with admin :) 1.4.1?

Thanks,

 - TK

-Preston

--
You received this message because you are subscribed to the Google Groups "Django developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/OvzZO5iQBl8J.