Open derikson opened 2 years ago
Hey @derikson, I'm not a contributor but I will tell you my opinion.
I'd say it's expected behavior, I faced the same case on my project and we weren't surprised to see a public tenant under a new thread even though it was not public in a parent.
Hi @derikson, I don't have a use case for fibers so for me it's harder to make an informed decision. I do have a use case where I switch the DB connection from a writer to a reader db and I have the apartment setting the same tenant on the new connection. All of this to say, I do understand your concern and maybe we can make it configurable.
I think what @derikson presented here should be considered a bug according to his code. lazy
shouldn't cause us to lose the current tenant.
@rpbaltazar I'm no longer working on a project that uses this gem, so I no longer have a use case that this solves. If nothing else, this bug report might help someone who is getting data from different tenants mixed together track down the cause.
Steps to reproduce
Expected behavior
All of the above should print "db1".
Actual behavior
Inside a new fiber, the fiber local variable
:apartment_adapter
no longer exists, so it creates a new one, set to the default tenant. Since enumerators are implemented using fibers, some enumerator methods use the default tenant instead of the tenant of the parent fiber.Apartment::Tenant.adapter
was probably meant to use thread local variables, but Ruby 1.9.2 changed the meaning ofThread#[]
andThread#[]=
to operate on fiber local variables instead of thread local variables. InsteadThread#thread_variable_get
andThread#thread_variable_set
should be used.System configuration
use_schemas
:true