Daniel Sokolowski's Blog

How to reuse custom defined 'models.Manager' QuerySets Django recommends to define custom query sets on your sublcassed models.Manager, there is one problem however that these are not chainable, that is you can only call your custom queryset once - assuming I have defined an '.active()' queryset the following will not work: >> PaymentTerm.objects.active().active() Traceback (most recent call last): File " ", line 1, in AttributeError: 'PaymentTermManager' object has no attribute 'active' >>> Current solutions on the web involve creating a subclassed 'models.Manager' and a custom 'QuerySet' which do work but are to code verbose for my linking. I believe the below approach is simpler, cleaner and more succinct. class OfferManager(models.Manager): ... STATUS_CHOICES = ( (STATUS_DISABLED, "Disabled"), (STATUS_ENABLED, "Enabled"), (STATUS_NEGOTIATED, "Negotiated")...

ERROR django.contrib.gis libgeos.py@80: GEOS_ERROR: ParseException: Unknown WKB type 0 These cryptic messages are caused by using the vanilla Django `model.Manager` with your geo enabled models. This caused me a frew hours of grief trying to figure it out, thinking it's the import data, or an issue with the third party app, etc. but the fix is to just extend your custom model manager from the `gis.models.GeoManager` which is super easy to forget: from django.contrib.gis.db import models class MyCustomManager(models.GeoManager): """ Additional methods / constants to Base's objects manager - using a GeoManager is fine even for plain models: ``BaseManager.objects.public()`` - all instances that are asccessible through front end """ # Model (db table) wide constants - we put these and not in model definition to avoid circular imports. # one can access these constants through .objects.STATUS_DISABLED or ImageManager.S...

IntegrityError: Problem installing fixtures: The row in table 'geonames_alternatename' with primary key '1830' has an invalid foreign key: geonames_alternatename.locality_id contains a value '109436' that does not have a corresponding value in geonames_locality.geonameid. In a situation where a third party app data export works just fine but the fixutre fails due to any IntegrityError is most likley cause by an overiden `objects` manager that returns only a subset. The solution is to explicitly tell django to export using the default model managers using the `--all` argument for example like so: dumpdata geonames --indent=4 --all --settings=settings_development > geonames_ext/fixtures/initial_data.json This is clearly a situation where explicit is better then implicit, that is when defining custom model managers do not touch the `get_query_set` method rather instead add an explict method; for post completeness below is my Eclipse PyDev template I utli...