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

2021-06-03 Thread N Aditya
ot even going to talk about the repercussions of using this approach with a ThreadPoolExecutor/ProcessPoolExecutor from within a view. Regards, Aditya N On Thursday, June 3, 2021 at 2:48:27 AM UTC+5:30 Aymeric Augustin wrote: > On 2 Jun 2021, at 07:49, N Aditya wrote: > > Below are

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

2021-06-01 Thread N Aditya
e best possible way. Regards, Aditya N On Wednesday, June 2, 2021 at 2:02:35 AM UTC+5:30 Aymeric Augustin wrote: > 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

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

2021-06-01 Thread N Aditya
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: >

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

2021-06-01 Thread N Aditya
explicitly. Regards, Aditya N 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

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

2021-06-01 Thread N Aditya
s looks like the closest option to the > intent you expressed. > > Best regards, > > -- > Aymeric. > > > > On 1 Jun 2021, at 12:09, N Aditya wrote: > > Hey all, > > I believe there's a major misunderstanding of what I've been trying to > convey. Le

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

2021-06-01 Thread N Aditya
or the CACHES dictionary would run into connection leaks/KeyErrors with such an approach. Regards, Aditya N On Tue, Jun 1, 2021 at 12:04 PM Florian Apolloner wrote: > > > On Monday, May 31, 2021 at 12:13:58 PM UTC+2 Adam Johnson wrote: > >> I'm also -1 on changing anything

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

2021-05-31 Thread N Aditya
Hey Adam/Simon, How can we take this forward ? Regards, Aditya N On Friday, May 28, 2021 at 3:04:14 PM UTC+5:30 N Aditya wrote: > Hey Adam, > > Also, after giving it a bit of thought, I figured that integrating this > logic with the routers framework isn't entirely necessary.

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

2021-05-28 Thread N Aditya
know your thoughts on the same. Regards, Aditya N On Friday, May 28, 2021 at 2:55:02 PM UTC+5:30 N Aditya wrote: > Hey Adam, > > "atomic does already call DB routers" -> Firstly after reading code, I > don't think the transaction APIs consult the routers. Secon

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

2021-05-28 Thread N Aditya
info that can be delivered to the transaction based on which a decision regd which DB to use could be made, then it would be cleanly isolated into its own method. Regards, Aditya N On Friday, May 28, 2021 at 2:03:16 PM UTC+5:30 Adam Johnson wrote: > Aditya - you didn't answer Simon's firs

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

2021-05-28 Thread N Aditya
saction_db_selector() if using is None: using = DEFAULT_DB_ALIAS return connections[using] Let me know your thoughts on this. Regards, Aditya N On Friday, May 28, 2021 at 10:05:26 AM UTC+5:30 charettes wrote: > Ticket that directed to the mailing list for w

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

2021-05-27 Thread N Aditya
>From the Django docs, for any ORM query made, the DB alias to use is determined by the following rules: - Checks if the using keyword is used either as a parameter in the function call or chained with QuerySet. - Consults the DB routers in order until a match is found. - Falls

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-14 Thread aditya
Mar 14, 6:27 am, James Bennett <ubernost...@gmail.com> wrote: > On Fri, Mar 12, 2010 at 4:39 PM, aditya <bluemangrou...@gmail.com> wrote: > > The trouble is, there is no straightforward way to configure the name > > and domain of a site. > > Sure there is: create a Si

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread aditya
A fixture won't really solve the problem. I'm okay with Gabriel's solution though. It is not as simple as my proposal, but certainly more elegant. Aditya On Mar 13, 6:57 am, Chuck Harmston <ch...@chuckharmston.com> wrote: > This particular use case (having predefined sets of informati

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-12 Thread aditya
Could you be more specific? I'm not sure what you mean. Aditya On Mar 12, 5:26 pm, Gabriel Hurley <gab...@gmail.com> wrote: > You seem to be missing the point of the code you reference above. You > should probably read up on the "Sites" framework that ships w

[Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-12 Thread aditya
Description = This page of the Django documentation shows how to use the 'Sites' framework to get the domain of the current site: http://docs.djangoproject.com/en/dev/ref/contrib/sites/ I've noticed that 'domain = Site.objects.get_current().domain' is becoming a common idiom in Django.

Adding a new convenience filter 'contains_any'

2010-03-04 Thread aditya
for any help you all can provide! Aditya -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developer

Re: Ticket resolved but not marked as such

2010-01-09 Thread aditya
Got it. Thanks. On Jan 9, 1:32 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Sat, Jan 9, 2010 at 2:24 PM, aditya <bluemangrou...@gmail.com> wrote: > > From what I can see, the following ticket: > > >http://code.djangoproject.com/ticket/4092 > > > is a

Ticket resolved but not marked as such

2010-01-09 Thread aditya
>From what I can see, the following ticket: http://code.djangoproject.com/ticket/4092 is addressing the same issue as this ticket: http://code.djangoproject.com/ticket/10969 Ticket #10969 is closed, but ticket #4092 is still marked as "new". Can we close #4092? Aditya --