DB Router not working on production machine, works on dev.

[Doug Ballance]

I've got a weird one I just can't figure out.  I'd love some help while I'm still sane.  

On my development machine all is well.  On the other machine the database router seems to be getting the parent class (which is an abstract model in another app).  I determined this with some print statements on the router(s):

    def db_for_read(self,model,**hints):
        print model
        print "router checked geo %s" % model._meta.app_label
        if model._meta.app_label in self.GEOAPPS:
             print "routed geo"
             return 'geo'
        return None


machine 1 (working):
In [1]: from glvar import models as gm
In [2]: gm.Listing.objects.count()
<class 'glvar.models.Listing'>
router checked geo glvar
<class 'glvar.models.Listing'>
router checked glvar glvar
routed glvar
Out[2]: 17373


Machine 2 (not working):
In [1]: from glvar import models as gm
In [2]: gm.Listing.objects.count()
<class 'feedbase.models.Listing'>
router checked geo feedbase
<class 'feedbase.models.Listing'>
router checked glvar feedbase
Out[2]: 0

The database is there and fine if I specify via using on machine2:
In [3]: gm.Listing.objects.using('glvar').count()
Out[3]: 25171

feedbase.models.Listing is the abstract base for glvar.models.Listing

The code is identical on both machines except for the settings.py file, confirmed by diff -qr on their respective directories.  I deleted all pyc files to make sure nothing funny was going on there.  The only differences there are in the name of the postgres user, and the library path for geos/gdal.  I updated both django versions to 1.6.5, so those are the same as well.  I'm not sure where I should begin tracking this down - suggestions?


(venv)[uidx@dev v3]$ diff app/app/settings.py prod/app/settings.py
49,50c49,50
< GEOS_LIBRARY_PATH = '/usr/lib/libgeos_c.so'
< GDAL_LIBRARY_PATH = '/usr/lib/libgdal.so'
---
> GEOS_LIBRARY_PATH = '/usr/lib64/libgeos_c.so'
> GDAL_LIBRARY_PATH = '/usr/lib64/libgdal.so'
142,143c142,143
<         'NAME': 'glvar',
<         'USER': 'uidx',
---
>         'NAME': 'glvar',
>               'USER': 'glvar',
148,150c148,150
<         'NAME': 'glvar_data',
<         'USER': 'uidx',
<         'PASSWORD': '<deleted>',
---
>         'NAME': 'glvar_data',
>         'USER': 'glvar',
>               'PASSWORD': '<deleted>',
239a240
>
243a245
>

[Doug Ballance]

The problem turned out to be an bug with an custom manager class based on djorm_pgfulltext search mixin.  I'd found an issue with it last week, and patched in the development environment but forgotten to patch the other machine.