Hidden Assumptions in django
12 assumptions this code never checks · 3 critical · spanning Domain, Contract, Scale, Ordering, Environment, Temporal
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at django/django and picked out the few most likely to cause trouble. The full list is just below.
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If SRID definitions are updated in the database (coordinate system changes, unit corrections), Django will continue using stale cached values, causing incorrect spatial calculations and wrong geographic results
If the stored value is corrupted geometry data or in an unexpected format, _load_func will raise exceptions during field access, causing crashes when accessing model attributes
If non-geometric Value expressions are passed at geometric parameter positions, spatial functions execute with invalid data, producing wrong spatial calculations or database errors
Show everything (9 more)
Assumes Oracle spatial tolerance value of 0.05 as default is appropriate for all geometric operations regardless of coordinate system units or data precision requirements
If this fails: For high-precision spatial data or coordinate systems with small units, 0.05 tolerance causes significant precision loss in spatial aggregations; for large-scale data, may cause unnecessary processing overhead
django/contrib/gis/db/models/aggregates.py:GeoAggregate.as_oracle
Assumes rhs_params tuple has exactly 1 element for most lookups or exactly 2 for 'relate' lookup, with band indices in specific positions
If this fails: If tuple length doesn't match expectations or band indices are in wrong positions, ValueError is raised but valid spatial queries with different parameter structures are rejected
django/contrib/gis/db/models/lookups.py:GISLookup.process_rhs_params
Assumes database-returned Decimal values can always be safely converted to float without precision loss for geometric area calculations
If this fails: For very large or very precise area measurements, converting Decimal to float loses precision, causing inaccurate spatial calculations in area-dependent operations
django/contrib/gis/db/models/sql/conversion.py:AreaField.from_db_value
Assumes _srid_cache defaultdict with database aliases as keys will not grow unboundedly and that database connections have stable, predictable alias names
If this fails: In deployments with dynamic database connections or connection pooling with varying aliases, cache grows without bounds causing memory leaks; inconsistent aliases cause cache misses and repeated SRID lookups
django/contrib/gis/db/models/fields.py:_srid_cache
Assumes mod_wsgi environ dict always contains username as a string and that UserModel._default_manager.get_by_natural_key() accepts any string input without validation
If this fails: If environ contains non-string username (None, bytes, int), get_by_natural_key() may raise TypeError; if username contains special characters or is malformed, database query errors occur
django/contrib/auth/handlers/modwsgi.py:check_password
Assumes user.is_active status is current and doesn't need revalidation, and that running default password hasher with empty string provides consistent timing
If this fails: If user is deactivated between authentication checks, inactive user may still authenticate; timing attack mitigation fails if default hasher performance varies across different environments
django/contrib/auth/handlers/modwsgi.py:_get_user
Assumes request object passed to ChangeList contains valid GET parameters that can be safely processed as filter, search, and pagination parameters without validation
If this fails: If request.GET contains malformed parameters (non-integer page numbers, invalid field names in filters), admin changelist fails with cryptic errors instead of graceful fallbacks
django/contrib/admin/views/main.py:ChangeList.__init__
Assumes SEARCH_VAR is always a string that can be used as a form field name, and that dynamic field population in __init__ happens before form validation
If this fails: If SEARCH_VAR is modified to contain invalid characters for form field names or if form validation occurs before field population, form creation fails with confusing errors
django/contrib/admin/views/main.py:ChangeListSearchForm.__init__
Assumes only int, float, and Decimal represent numeric types for spatial functions, excluding numpy types, complex numbers, or custom numeric classes that may be used with geographic data
If this fails: Spatial functions reject valid numeric types like numpy.float64 or custom measurement classes, forcing unnecessary type conversions and reducing interoperability with scientific computing libraries
django/contrib/gis/db/models/functions.py:NUMERIC_TYPES
See the full structural analysis of django: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of django/django →Frequently Asked Questions
What does django assume that could break in production?
The one most likely to cause trouble: Assumes SRID (Spatial Reference System Identifier) values in the spatial_ref_sys table are immutable and can be cached indefinitely in _srid_cache without expiration or invalidation If this fails, If SRID definitions are updated in the database (coordinate system changes, unit corrections), Django will continue using stale cached values, causing incorrect spatial calculations and wrong geographic results
How many hidden assumptions does django have?
CodeSea found 12 assumptions django relies on but never validates, 3 of them critical, spanning Domain, Contract, Scale, Ordering, Environment, Temporal. Most are routine — the analysis flags the two or three most likely to actually bite.
What is a hidden assumption?
Something the code depends on but never checks: a data shape, an ordering, an environment condition, a scale limit, or a contract with another service. It holds until the world it runs in changes, then fails silently.