Closed ReneB closed 1 year ago
We can't use the Address
class, since that has a foreignkey to user. Also, if we're only going to display this info to the user and not process it in any way, it probably does not make much sense to add this extra structure and just using one field is fine.
Does Django not have any kind of polymorphic relations?
I would suppose it could be processed by, for example, generating a Google Maps link for it or something similar (and/or more open, such as https://www.openstreetmap.org)
Yeah, there could be a polymorphic relation, but that would probably reduce flexibility by tying the two kinds of addresses together. As for Maps links, I would just put an explicit link in the location description (which should probably be markdown or some other markup).
but that would probably reduce flexibility by tying the two kinds of addresses together.
Wait, I don't understand. If the Address has a polymorphic reference to its "owner" so to say, there would still only be one Address type, right? They only have a street address, postal code, city and country. What kind of flexibility would we loose? And if any, would Django also support something like Single Table Inheritance to allow multiple types of addresses to be stored in the same table?
They only have a street address, postal code, city and country. What kind of flexibility would we loose?
The flexibility to customize the address model for use with either user or event. E.g., (stupid example), we might want to add a "nearby parking" field to the location address, or a "type" (visit/postal/home/work/whatever) to a user address, without also affecting the other. This is probably fixable by adding more complexity (specific subclasses for example), but I'm not sure there is any additional gain.
This is just a secondary argument, though, my primary argument would be that there is no realy need for this structure, so it adds complexity while at the same time limiting the expressivity over just a free-form text field.
And if any, would Django also support something like Single Table Inheritance to allow multiple types of addresses to be stored in the same table?
Not entirely sure what you mean here, but django supports inheritance in two ways: The simplest is superclasses acting as a sort of template, where subclasses copy their fields but get a separate and unrelated database table, where the other more complex with superclasses having their own table, which is referenced as the parent from subclass tables.
I can definitely agree with your primary argument. Although I still think that at some point, the address for a location might be a little more formalized instead of just a free-form field, for now it's not worth the trouble, especially since we don't yet know what this feature should "look like" and enable.
Side note: there are three well-known, distinct flavors of mapping classes to database tables:
Single Table Inheritance, Concrete Table Inheritance and Class Table Inheritance. From your description, both options sound like "Class Table Inheritance" although, if I understand you correctly, the second option might be construed as a "fourth flavor" since a single object is spread out over multiple records in multiple database tables, right?
AFAICS, the ones I described are concrete table inheritance and class table inheritance (the latter has a single object spread over multiple tables AFAIU from your link).
I'm going to close this - it seems the current free-form text system works well enough and there is more than enough other features to invest time in, so I'll probably never come around to this.
If this system can more or less be used as a registration HUB, players should probably also be able to see where they 're supposed to travel and such.
There is a free-form "Description" field now, but we could probably also use
Address
for this part.