Context stickiness

[Igor Belo]

How does distribute_reads handle the context stickiness provided by makara?

I like the idea of this gem by directing the traffic to primary database by default and not the other way around, but something really useful in makara is how the context is stuck if it's in the same flow of execution. So sticky: true seems to be pointless, for example:

User.create!(...params) #primary
User.all #primary

But if I try the same using distribute_reads:

User.create!(...params) #primary
distribute_reads { User.all } #replica

I also like that makara stores the context between two requests, since some delay between primary and replica data sync might be involved.

Is there any way to achieve that?

[Andrew Kane]

Hey @igorbelo, if you set DistributeReads.by_default to true, it will follow Makara’s stickiness behavior outside of distribute_reads blocks.

[Igor Belo]

Hey @ankane thanks for the quick response.

I was hoping that would be possible for distributed_reads blocks to respect makara current context.

My use case is simple:

• I want by default all queries to go to master/primary without forcing it
• I want read queries to go to replicas explicitly declaring it UNLESS there's a current context telling otherwise (partly possible)

The only way that I see it possible is by using something like:

distributed_reads(primary: something_dynamic) { ... db calls }

This something_dynamic would be a call to makara checking if current context is master, not sure if it's possible though.

[Andrew Kane]

Makes sense. I don't see a strong reason to incorporate another pattern into the gem, but you should be able to fork it to achieve this.