Django Database Cache Behavior Analysis

You've identified some discrepancies between the Django documentation and the actual implementation of the database cache backend. Based on the documentation provided, you're correct in your observations.

Documentation vs. Implementation

The documentation states:

Unlike other cache backends, the database cache does not support 
automatic culling of expired entries at the database level. Instead, expired cache entries are culled each time 
add(), set(), or touch() is called.

However, your analysis of the code reveals:

1. Expired entries are only culled when MAX_ENTRIES is reached, which triggers the culling mechanism
2. The culling mechanism can also remove non-expired entries if the total number exceeds MAX_ENTRIES
3. The documentation doesn't mention that expired entries are also removed when calling get()

The Issue

This creates a problematic situation where:

• To avoid random culling of non-expired entries, you'd need to set MAX_ENTRIES very high
• But setting MAX_ENTRIES high prevents the culling mechanism from triggering, which means expired entries aren't removed

Possible Solutions

You're right that the documentation appears to be incomplete. The behavior you're describing does seem to contradict what's documented. Based on your needs for time-based expiration without random culling, you might consider:

1. Filing a documentation issue to clarify the actual behavior
2. Submitting a feature request or pull request to modify the database cache backend to cull expired entries regardless of whether MAX_ENTRIES is reached
3. Implementing a custom cache backend that extends the database backend but modifies the culling behavior to match your requirements

The current implementation does seem to have limitations for use cases that rely solely on time-based expiration without the random culling behavior.