-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
current tenant is lost when creating a new fiber #181
Comments
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. |
I think what @derikson presented here should be considered a bug according to his code. |
@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
Postgres 12.6
2.9.0
use_schemas
:true
6.1.4.4
2.7.5
The text was updated successfully, but these errors were encountered: