Replies: 1 comment 6 replies
-
Hi @morrah, Thanks for reaching out. As I understand it, you are asking first about the cache timeout and second about ids. I'll try to answer them one by one: Cache timeoutThe answer to that is relatively simple. It is recommended your cache backend. I would advise you to set the appropriate timeout for that backend depending on your application. HASH vs UUIDIt's not as simple as you make it out to be. No only could you have two querysets on the same table, but you could build forms and widgets dynamically. All of which I and many other users have done in the past. This ruins the deterministic approach. However, that is something we do in Django's admin. However, this package provides functionality that goes beyond that. Having a UUID as an identifier to retrieve the correct query information works for all cases. I hope that answers you questions. Best, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Default cache TTL is 300s, but default django session is 2 weeks; user could want to have a page opened for almost 2 weeks but 5 minutes later he gets 404 responses only.
Does it make sense to set default timeout for select2 cache to a first explicitly declared timeout or to a default session age otherwise?
Kinda
Also another question somehow linked to caching.
Curious about reasons behind using
uuid
for every widget instance instead of predictable hashing for a db field - 'database name + table name + column name' as a hash input for example.Thus we don't need to use cache as an external consistent storage for
uuid
s, because every django process can calculate this same field_id on its own.Though it requires to whitelist somewhere (in
settings
?) select2-accessible db fields. What are the other downsides?Beta Was this translation helpful? Give feedback.
All reactions