I am using Multi-Table inheritance (aka Concrete Inheritance), where I have a non-abstract model + DB Table called Clients, which is concerned with common details concerning all the clients.
But a client can be an Individual, Partnership or Company, for which I have created inheriting models and tables. An Individual has first name + last name, and company has other specific particulars, etc.
I want to be able to access the names of clients (derived from the columns from the child tables) when I want a list of all clients.
After lot of searching, I found that this tutorial, works successfully.
Basically, it involves inserting a column on the Client table, which will store the name of the Child model. Then using that name, the appropriate child model is identified and appropriate child method is accessed.
But it seems to be a slightly cumbersome way to implement polymorphism in Multi-Table inheritance.
I want to know whether since 2012, Django has introduced any better way to deal with the issue, or is this still the only way?
Please let me know if my code sample is required, but the link provided has a beautiful example already.
There is django-model-utils application with Inheritance Manager. It will cast automatically your parent class to children instances. Example from docs:
from model_utils.managers import InheritanceManager
class Place(models.Model):
# ...
objects = InheritanceManager()
class Restaurant(Place):
# ...
class Bar(Place):
# ...
nearby_places = Place.objects.filter(location='here').select_subclasses()
for place in nearby_places:
# "place" will automatically be an instance of Place, Restaurant, or Bar
Also check this question for generic solution with ContentType.
And also check awesome article by Jeff Elmore about this topic. Quite old, but still great.
Related
Summary: Is it possible to access a model sub-classed via multi-table inheritance via a relatedmanager on a related model instance?
Details:
Assuming the following model definitions..
class City(models.Model):
...
class Place(models.Model):
city = models.ForeignKey(City)
class Restaurant(Place):
...
I'd like to be able to access all restaurants in the city of Portland like this:
portland = City.objects.get(id=1)
portland.restaurant_set.all()
However restaurant_set or similiar doesn't seem to be an exposed RelatedManager on City, only place_set is exposed.
Is there a way to expose restaurant_set, restaurants, or similar as a related manager when accessing a model instance of City?
I've also tried created a custom manager for Restaurant, like this:
class RestaurantManager(models.Manager):
use_for_related_fields = True
class Restaurant(Place):
objects = RestaurantManager()
However it doesn't seem to get me any closer to what I want.
Apologies in advance as this is just pseudo-code, not the actual models I'm using in my project/app. It's possible I've introduced an error here not in my actual code base, and will happily clarify and update if so.
Also, if it's possible to accomplish this without the use of a 3rd party package (like django-polymorphice etc) I'd prefer that, but if the only reasonable way is to use one of these packages, I will accept that as the answer.
Finally, I'm on Django 1.8 and cannot upgrade for the time being.
I'm currently working on a model in Django involving one model that can have a variety of different traits depending on what kind of object it is. So, let's say we have a model called Mammal, which can either be an Elephant or a Dolphin (with their own traits "tusk_length" and "flipper_length" respectively).
Basic OOP principles shout "polymorphism", and I'm inclined to agree. But, as I'm new to Django, I first want to know whether or not it is the best way to do so in Django. I've heard of plenty of examples of and some people giving their preferences toward singular giant models
I've already tried using GenericForeignKeys as described here: How can I restrict Django's GenericForeignKey to a list of models?. While this solution works beautifully, I don't like the inability to filter, and that the relationship is only one way. That is, while you can get a Dolphin from a Mammal object, you can't get the Mammal object from the Dolphin.
And so, here are my two choices:
Choice A:
from django.db import models
class Mammal(models.Model):
hair_length = models.IntegerField()
tusk_length = models.IntegerField()
flipper_length = models.IntegerField()
animal_type = models.CharField(max_length = 15, choices = ["Elephant", "Dolphin"]
Choice B:
from django.db import models
class Mammal(models.Model):
hair_length = models.IntegerField()
class Elephant(Mammal):
tusk_length = models.IntegerField()
class Dolphin(Mammal):
flipper_length = models.IntegerField()
Choice B, from what I understand, has the advantage of nicer code when querying and listing all Elephants or Dolphins. However, I've noticed it's not as straightforward to get all of the Elephants from a list of Mammals (is there a query for this?) without putting animal_type in the class, with default being dependent on the class.
This leads to another problem I see with polymorphism, which won't come up in this example above or my application, but is worth mentioning is that it would be difficult to edit a Dolphin object into an Elephant without deleting the Dolphin entirely.
Overall, is there any general preference, or any big reason I shouldn't use polymorphism?
My recommendation, in general with database design, is to avoid inheritance. It complicates both the access and updates.
In Django, try using an abstract class for your base model. That means a db table will not be created for it. Its fields/columns will be auto-created in its child models. The benefit is: code reuse in Django/Python code and a simple, flat design in the database. The penalty is: it's more work to manage/query a mixed collection of child models.
See an example here: Django Patterns: Model Inheritance
Alternatively, you could change the concept of "Mammal" to "MammalTraits." And include a MammalTraits object inside each specific mammal class. In code, that is composition (has-a). In the db, that will be expressed as a foreign key.
We ended up going with a large table with a lot of usually-empty columns. Our reasoning was that (in this case) our Mammal table was all we'd be querying over, and there was no (intuitive) way to filter out by certain types of Mammals besides manually checking whether they had a "dolphin" or "elephant" object, which then threw an error if they didn't. Even looking for the type of an object returned from a query that was definitely an Elephant still returned "Mammal". It would be hard to extend any Pythonic workarounds to writing pure SQL, which one of our data guys does regularly.
I need an elegant way of disabling or authorizing related field traversal in Django templates.
Imagine following setup for models.py:
class Person(models.Model):
pass
class Secret(models.Model):
owner = models.ForeignKey(Person, related_name="secrets")
Now imagine this simple view that gives the template QuerySet of all Person instances in the system just so the template could put them in a list.
def show_people(request):
render_to_response("people.html", {people=Person.objects.all()})
Now my problem is that I would not provide the templates myself in this imaginary system and I don't fully trust those who make the templates. The show_people view gives the people.html template the secrets of the Person instances through the related_name="secrets". This example is quite silly but in reality I have model structures where template providers could access all kind of vulnerable data through related managers.
The obvious solution would be not to give models to templates but to convert them in to some more secure data objects. But that would be pain in my case because the system is already quite big and it's up and running.
I think a cool solution to this would be somehow preventing related field traversal in templates. Another solution would be to have such custom related managers that could have access to the request object and filter the initial query set according to the request.user.
A possible solution could be to use a custom model.Manager with your related models.
Set use_for_related_fields = True to force Django to use it instead of the plain manager. modify the manager to filter the data as needed.
also have a look at this:
Django: using managers for related object access (use_for_related_fields docs)
stackoverflow: use_for_related_fields howto, very good explanation here.
I'm working on a django-nonrel project running on Google's AppEngine. I want to create a model for a Game which contains details which are generally common to all sports - i.e. gametime, status, location, etc. I've then modelled specific classes for GameBasketball, GameBaseball etc, and these inherit from the base class.
This creates a problem however if I want to retrieve something like all the Games on a certain day:
Game.objects.filter(gametime=mydate)
This will return an error:
DatabaseError: Multi-table inheritance is not supported by non-relational DBs.
I understand that AppEngine doesn't support JOINs and so it makes sense that this fails. But I'm not sure how to properly tackle this problem in a non-relational environment. One solution I've tried is to turn Game into an abstract base class, and while that allows me to model the data in a nice way - it still doesn't resolve the use case above since its not possible to get objects for an abstract base class.
Is the only solution here to put all the data for all possible sports (and just leave fields that aren't relevant to a specific sport null) in the Game model, or is there a more elegant way to solve this problem?
EDIT:
I'm more interested in understanding the correct way of handling this type of issue in any noSQL setup, and not specifically on AppEngine. So feel free to reply even if your answer isn't GAE specific!
For anyone else who has this issue in the future, here is how I eventually went about resolving it. Keep in mind that this is somewhat of a mongo-specific solution, and AFAIK there is no easy way to solve this just using base nonrel classes.
For Mongo I able to solve this by using Embedded Documents (other noSQL setups may have similar soft-schema type features), simplified code below:
class Game(models.Model):
gametime = models.DateTimeField()
# etc
details = EmbeddedModelField() # This is the mongo specific bit.
class GameBasketballDetails(models.Model):
home = models.ForeignKey(Team)
# etc
Now when I instantiate the Game class I save a GameBasketballDetails object in the details field. So I can now do:
games = Game.objects.filter(gametime=mydate)
games[0].details.basketball_specific_method()
This is an acceptable solution since it allows me to query on the Game model but still get the "child" specific info I need!
The reason multi-table inheritance is disallowed in django-nonrel is because the API that Django provides for those sort of models will often use JOIN queries, as you know.
But I think you can just manually set up the same thing Django would have done with it's model inheritance 'sugar' and just avoid doing the joins in your own code.
eg
class Game(models.Model):
gametime = models.DateTimeField()
# etc
class GameBasketball(models.Model):
game = models.OneToOneField(Game)
basketball_specific_field = models.TextField()
you'll need a bit of extra work when you create a new GameBasketball to also create the corresponding Game instance (you could try a custom manager class) but after that you can at least do what you want, eg
qs = Game.objects.filter(gametime=mydate)
qs[0].gamebasketball.basketball_specific_field
django-nonrel and djangoappengine have a new home on GitHub: https://github.com/django-nonrel/
I'm not convinced, next to the speed of GAE datastore API itself, that the choice of python framework makes much difference, or that django-nonrel is inherently slower than webapp2.
Here's the deal:
I got two db models, let's say ShoppingCart and Order. Following the DRY principle I'd like to extract some common props/methods into a shared interface ItemContainer.
Everything went fine till I came across the _flush() method which mainly performs a delete on a related object set.
class Order(models.Model, interface.ItemContainer):
# ...
def _flush(self):
# ...
self.orderitem_set.all().delete()
So the question is: how do I dynamically know wheter it is orderitem_set or shoppingcartitem_set?
First, here are two Django snippets that should be exactly what you're looking for:
Model inheritance with content type and inheritance-aware manager
ParentModel and ChildManager for Model Inheritance
Second, you might want to re-think your design and switch to the django.contrib content types framework which has a simple .model_class() method. (The first snippet posted above also uses the content type framework).
Third, you probably don't want to use multiple inheritance in your model class. It shouldn't be needed and I wouldn't be surprised if there were some obscure side affects. Just have interface.ItemContainer inherit from models.Model and then Order inherit from only interface.ItemContainer.
You can set the related_name argument of a ForeignKey, so if you want to make minimal changes to your design, you could just have ShoppingCartItem and OrderItem set the same related_name on their ForeignKeys to ShoppingCart and Order, respectively (something like "item_set"):
order = models.ForeignKey(Order, related_name='item_set')
and
cart = models.ForeignKey(ShoppingCart, related_name='item_set')