[Django]-Django Nonrel – Working around multi-table inheritance with noSQL?

0👍

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.

1👍

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!

Leave a comment