Hello Juan, indeed I've used the approach of setting the schema on the connection checkout for a while.
We used to support a single template and have been asked to support 4 templates in a short time. The quickest solution I could think of at that time that could work without impacting a lot on the application, since the test coverage was pretty low, was to keep everything basically the same while keeping each template in a different schema. This wasn't the ideal solution. Ideally I'd prefer to include a new template_id field to the fields table, however, we wouldn't be able to deliver the solution in time by the time this has been requested. So, for a while we went with this plan, but we eventually had to move to the other solution at some point. We had to create many more templates after that, and some templates were special ones that would actually map to other existing templates. The schema based approach wouldn't work well for handling such cases. In the end we had to spend even more time to migrate the templates to the new database design, so, if you are not in a rush, I'd recommend you to avoid using different schemas for handling multi-tenant and similar use cases as much as possible, as at some point you'll have to face some problems that are harder to solve with the multi-schema design. Believe me, performance is the last thing you should be worried about. Best, Rodrigo. Em dom., 5 de set. de 2021 às 13:06, [email protected] < [email protected]> escreveu: > > > On Wednesday, January 9, 2013 at 1:19:26 PM UTC-3 Jeremy Evans wrote: > >> On Wednesday, January 9, 2013 6:56:06 AM UTC-8, Rodrigo Rosenfeld Rosas >> wrote: >>> >>> Yes, I understand, but maybe the performance hit would be smaller than >>> the other simple alternative (limiting concurrent requests to available db >>> connections through Database.synchronize Rack middleware). >>> >>> But I guess there isn't any after_checkout hook, right? >>> >> >> There isn't, but that's basically what the connection_validator extension >> does. So take a look at that plugin's implementation if you want to figure >> out how to run code on each checkout. >> > > Hi Rodrigo, I know this is an old thread, but I wonder if you ever tried > the approach of setting the schema on every connection checkout and > measured the performance hit. > > I'm looking at different approaches about ensuring the same schema is used > for a single request. Although I agree that qualifying the statements is > the best solution (and I would love to take that path) putting the > qualifier in the models seems a little risky to me, as access to the > database could also happen without using the models. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sequel-talk" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sequel-talk/88x5BKr61p4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sequel-talk/ff0d89ba-8ed1-42ed-804c-e812a0242e56n%40googlegroups.com > <https://groups.google.com/d/msgid/sequel-talk/ff0d89ba-8ed1-42ed-804c-e812a0242e56n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CAGmv%2BwKVcRVF5rT%3DpMAgpetSPZ2-at9nrq_376izGLxkxSjpKw%40mail.gmail.com.
