Hi Rodrigo, Thanks for the detailed explanation. I did a quick test of setting the schema on each connection checkout and indeed it worked well, but that extra statement made me go for the dynamic schema qualification that Jeremy suggested. It turned out to be not as complicated as I thought it would be, and it worked pretty well.
Anyway, I appreciate your advice on the multi-schema design though and I'll consider changing the design to a different approach. Thanks Juan On Mon, Sep 6, 2021 at 6:28 PM Rodrigo Rosenfeld Rosas <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/sequel-talk/CAGmv%2BwKVcRVF5rT%3DpMAgpetSPZ2-at9nrq_376izGLxkxSjpKw%40mail.gmail.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/CALXCfb3QVq-nKdN2nXN19FmUyNqeOQzgZbQOQ%2B50p1K7pjKpcQ%40mail.gmail.com.
