>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 bac
Hey Simon,
It would be possible to write a method as you've suggested above. But it
entails the following problems:
1. There would have to be a wrapper for each of the transaction APIs, not
just transaction.atomic since all of them take the using kwarg.
2. I'm trying to build a library that he
fferent result for atomic() than for a write query?
>
> On Fri, 28 May 2021 at 09:17, N Aditya wrote:
>
>> Hey Simon,
>>
>> It would be possible to write a method as you've suggested above. But it
>> entails the following problems:
>> 1. There would ha
.
Let me 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
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 necess
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
runtime
> isn't officially supported, but this 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 m
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
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
butor in the long run and do some
exciting work. Let me knw how we can take this forward in the 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 l
using a thread-sync
primitive. I'm not 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 0
11 matches
Mail list logo
