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 respective router methods. Is your expectation that the router somehow detect that there's an open transaction block somewhere above and scope all reads/writes that happen within it to be routed to the DB it was tied to ? i.e the DB alias used by the transaction takes precedence over what the router methods namely db_for_read/db_for_write may return. If this is your expectation, I think it might be hard to bake this into core Django. We could receive more views on the same from the community. Looking at it from another perspective, I believe this can be achieved externally if core Django could expose hooks such as transaction.on_enter / transaction.on_exit to which callbacks can be hooked which could set some state info in thread-locals/contextvars which can later be parsed by the db_for_read/db_for_write methods to determine whether to use this info to make its decision or fallback to the default behaviour. Also, something I'd like to clarify is that my use-case for a hook such as *db_for_transaction* is different. You could read above to know more about this. Regards, Aditya N On Tuesday, June 1, 2021 at 11:34:55 PM UTC+5:30 lokeshw...@gmail.com wrote: > 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_write(self, model, **hints): > return 'default' > > def allow_relation(self, obj1, obj2, **hints): > return None > > def allow_migrate(self, db, app_label, model_name=None, **hints): > return None > > So this is all fine for normal queries. But we observed that even within a > transaction.atomic() block, the read queries go to a different database, > and write queries go to a different database > > So I was hoping *db_for_transaction* proposal may improve this behavior. > On Tuesday, June 1, 2021 at 6:32:44 PM UTC+5:30 f.apo...@gmail.com wrote: > >> 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 the longrun. >> >> A simple implementation can be: (From message-3 of this conversation): >>> >>> >>> > #settings.py >>> >>> TRANSACTION_DB_SELECTOR = "path_to_some_callable" >>> >>> #transaction.py >>> ... >>> transaction_db_selector = import_string(settings.TRANSACTION_DB_SELECTOR) >>> def get_connection(): >>> if transaction_db_selector: >>> using = transaction_db_selector() >>> if using is None: >>> using = DEFAULT_DB_ALIAS >>> return connections[using] >>> >> >> I do not think that completely ignoring the `using` that was passed in by >> the user would be a very good idea (for the case when there is also a >> `TRANSACTION_DB_SELECTOR` set). >> >> Cheers, >> Florian >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4375763e-7e48-4426-bc49-587fdbba12c9n%40googlegroups.com.
