Great! You said before to store connections in a hash with the tenant name.. Do you think it works to store those Connection objects serialized to a Cache storage system like Redis?
Its the only think persistent enough to not be in-memory i can think. ][`s Em terça-feira, 31 de julho de 2018 13:29:45 UTC-3, Jeremy Evans escreveu: > > On Tuesday, July 31, 2018 at 8:40:12 AM UTC-7, Renato Alves wrote: >> >> Help me clarify this sharding concept. >> In my application, i dont actually own the database who i am connecting. >> They are provided by the Customer and i just do the middle layer >> manipulating the database to insert things. >> How would you apply sharding to that situation? >> > > If all of the databases have different schema, then sharding is not > appropriate, and you do want to use separate Sequel::Database objects (this > sounds like your case). If all databases have the same schema, then using > the sharding support is usually simpler than managing multiple > Sequel::Database objects. > > Thanks, > Jeremy > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
