Re: Transaction APIs do not consult the DB router to choose DB connection

Hey all, I believe there's a major misunderstanding of what I've been trying to convey. Let me rephrase: *Problem*: Include the request object as a decision param in the routers framework/transaction APIs based on which a DB can be chosen i.e all queries(reads/writes) and transactions are directe

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, The first item in Django's design philosophies is Loose coupling . Per this principle, the database layer shouldn't know about the HTTP layer. This is a strong reason for keeping the HTTP request object aw

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey, I agree to the fact that the request object being passed to the DB layer (routers/transaction APIs) may not be pragmatic according to the Loose coupling approach. Quoting what you said: > you can store the current HTTP request as a thread-local variable in your application and access i

Re: Transaction APIs do not consult the DB router to choose DB connection

On Tuesday, June 1, 2021 at 1:45:29 PM UTC+2 Aymeric Augustin wrote: > I would recommend running without persistent database connections > (CONN_MAX_AGE = 0) and switching settings.DATABASE["default"] in a > middleware at the beginning of every request. Modifying settings at runtime > isn't off

Re: Transaction APIs do not consult the DB router to choose DB connection

On Tuesday, June 1, 2021 at 2:35:17 PM UTC+2 gojeta...@gmail.com wrote: > I don't see any reason for why providing a hook seems so difficult. > It is more code to maintain, needs tests etc and increases complexity. Just because something is easy on the surface, doesn't mean it will be easy in

`Model.validate_unique` excluding partial unique constraint

Hi, I changed several models from fields using `unique=True` to using `UniqueConstraint` with a condition in the Meta. As a side-effect, the uniqueness are no longer validated during cleaning of a Form and an integrity error is raised. This is because partial unique indexes are excluded : http

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Florian, I'd like to point out that the code snippet which I wrote is just a scratch version of how it might look. I'd first like to reach consensus on the idea itself before writing something concrete. Obviously it wouldn't be as naive as overriding something that the user provided expli

How to do a counter in DB cache class?

This might be more of a Python question than a Django one, but in this ticket I'm hoping to make the DB cache a bit more performant by having it not cull stale entries *every* time somebody adds, changes, or touches a cache key. The idea is to use

Re: Transaction APIs do not consult the DB router to choose DB connection

Hi Everyone, Our use case is that we have a writer primary database and read-only replica databases. The replicas can sometimes be a bit behind the primary We have written a Router like this class CustomRouter: def db_for_read(self, model, **hints): return 'reader' def db_for_wr

Re: How to do a counter in DB cache class?

Hi Mike! Probabilistic culling probably is the best we can do in the DB cache, aside from moving culling to a background task. I wrote an implementation of this probabilistic culling in the django-mysql cache backend (which is mysql only): https://django-mysql.readthedocs.io/en/latest/cache.html#

Re: How to do a counter in DB cache class?

Wow, that's pretty great! Did you consider merging this functionality into django itself? I hadn't seen anything related before now. On Tue, Jun 1, 2021 at 11:38 AM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > Hi Mike! > > Probabilistic culling probably is the b

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Lokesh, Just out of curiosity, I'd like to clarify the expected behaviour. If a db_for_transaction method is implemented, I believe it would be consulted for transaction APIs like atomic etc., Reads and writes which happen within that transaction are nevertheless going to consult their r

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, > On 1 Jun 2021, at 14:35, N Aditya wrote: > > All I'm looking for is a hook that the transaction APIs can call before > deciding on which database to use. I don't see any reason for why providing a > hook seems so difficult. Just because something is easy to implement doesn't mean it

Re: `Model.validate_unique` excluding partial unique constraint

Hello there, Partial unique constraints are currently not supported during validation for reasons described in this ticket[0]. For example (inspired by this Github comment[1]), if you define the following model class Article(models.Model): slug = models.CharField(max_length=100) delete

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Augustin, Just to clarify, from before, you quoted: > you can store the current HTTP request as a thread-local variable in your application and access it from anywhere, for example from a database router. Also, from your previous message, you quoted > As a consequence, the only way to make i