Last week I had to cope with one of the (few!) limitations of Django ORM model about inheritance. For the GeoDjango website we are developing, we created a model that stores user-layer pairs, so that a logged user can restore the state of map and legend as [s]he left it at previous login, and anonymous users receive a default list of layers. Here is the code for the model:
class UserWmsLayer( models.Model ):
""" Stores custom user preferences for a layer. """
wmslayer = models.ForeignKey( WmsLayer )
user = models.ForeignKey( User )
is_visible = models.NullBooleanField( null=True, blank=True )
is_deleted = models.NullBooleanField( null=True, blank=True, default=False )
The Layers in Legend can be of WmsLayer class or any of its subclasses, at the moment the only subclass is DateQueryLayer, a WMS layer with a filter on the date attribute. We also have a Layer class, that is an ABC (Abstract Base Class), but it’s not possible to create a ForeignKey to an ABC as it has no table in the database. So we decided to create the ForeignKey to WmsLayer as a working, half-hack solution.
That worked nicely until I relied on inheritance and method overriding. I expected Django to store the ForeignKey to the actual class of the object, but the ORM stores it as a reference to the superclass, in our case of WmsLayer. This is very well explained in enlightening answer #4 of this stackoverflow QA.
In few words, I can actually have a User-DateQueryLayer pair, but in the model it will be stored as WmsLayer, and all methods I call will be WmsLayer‘s, not DateQueryLayer‘s as I would expect from OO programming. DateQueryLayer redefines asOpenLayer method, but due to this ORM limitation I could never call it.
The solutions were multiple, more or less Pythonic, Django-ish, brittle and scalable. I took two days to google and get through them, and the only two applicable solutions seemed to be:
- Run Time Type identification via a ifelse cascade: that would be the less scalable and most brittle hack.
- Django’s Generic Relations: better, but still overcomplicated.
I was about to implement Generic Relations when I realised that asOpenLayers() simply returns a JavaScript string. A simple solution came to me in a flash. Instead of creating the JavaScript code on the fly every time the layer is used somewhere, I decided to store that string into an attribute owed by Layer, the abstract superclass, so that all subclasses will simply inherit it and populate it at instantiation time using their own asOpenLayers method. The User-*Layer pair will therefore rely on an attribute in WmsLayer table without any inheritance issue.
Here is what the relevant code looks like:
class Layer( models.Model ):
"""This is an ABC (Abstract Base Class) for all models that are layers.
It provides common api so that all layers can be treated in a similar way."""
name = models.CharField( max_length=256 )
owner = models.ForeignKey( User, related_name = 'owner' )
# store the javascript as *attribute*, instead of generating it on-the-fly
as_open_layer = models.TextField( )
class WmsLayer( Layer ):
url = models.URLField( max_length=1024, verify_exists=True )
layers = models.CharField( max_length=256 )
# link to user-layer model to keep status of legend
users = models.ManyToManyField(User, through='UserWmsLayer')
def asOpenLayer( self ):
"""Return a string representation of this model as an open layers
layer definition. The created layer def will be added
to the openlayers map of name theMap (which defaults to "map". """
return "the JavaScript string" #omitted for brevity
def save( self, *args, **kwargs ):
""" Overrides standard save, generating the asOpenLayers javascript
and storing it into as_open_layer attribute. """
self.as_open_layer = self.asOpenLayer()
super(WmsLayer, self).save( *args, **kwargs)
class DateQueryLayer( WmsLayer ):
"""A layer model for storing user date range queries persistently"""
date_query_type = models.ForeignKey( DateQueryType )
sensor = models.ForeignKey( Sensor )
start_date = models.DateTimeField( null=True, blank=True )
end_date = models.DateTimeField( null=True, blank=True )
def asOpenLayer( self ):
""" Overrides WmsLayer's method. """
return "the JavaScript string" #omitted for brevity
def save( self, *args, **kwargs ):
self.as_open_layer = self.asOpenLayer()
super(DateQueryLayer, self).save( *args, **kwargs)
That’s it.
Once you filter the UserWmsLayer table by user, you won’t call anymore the asOpenLayer method…
myObjects = UserWmsLayer.objects.filter(user__username = "anonymous")
for myObject in myObjects:
myObjects.asOpenLayer()
… but fetch the as_open_layer attribute instead!
myObjects = UserWmsLayer.objects.filter(user__username = "anonymous")
for myObject in myObjects:
myObjects.as_open_layer
This allows you to pick up the correct string, without worrying about which type myObject is. This is good. Clean. Scalable. Pythonic. Yes, the asOpenLayer method simply returns a string according to some Layer properties, this solution could not work with more complex methods. But if you face a similar inheritance issue, and your method returns something that can be stored in an attribute of the superclass, that’s one of the cleanest solutions I’m aware of.
Hope this helps, and better solutions are most welcome 
Happy coding,
–anne
For those interested in setting up large filesystems, you may be interested to know that we are using ext4 on both storage arrays. We are using one massive partition on each, and so far the filesystems have been extremely reliable. In order to create such a large partition just be sure to use parted (or gparted for you point & clickers) and use GPT for the partition table.
