On Thursday, October 5, 2017 at 12:35:44 PM UTC-7, Greg Burek wrote:
>
> Hello,
> We use sequel models extensively, including single table inheritance for
> implementing different class behaviors, while sharing tables, all to
> implement a server and service management and orchestration platform.
>
> We also use a ruby pry console to interact with our app and trigger
> actions in production. In an effort to avoid fat fingers and other errors
> from accidentally killing our fleet, we implemented a default read only
> console, which initially connects to our read replica, and on demand,
> allows an operator to change to a writeable console. This runtime action
> disconnects DB and reconnects to our writable leader, while preserving
> already loaded Sequel::Model objects in memory. Our current method of doing
> this reassigns db for all loaded Sequel::Model.descendants, so that already
> loaded Sequel objects may be preserved and be able to write to the proper
> db, after making the console writable.
>
> Now we are looking to move to Sequel 5, where it seems that setting a
> Model.db= is not possible. We attempted to move to using Model.dataset= to
> achieve the same effect, but then found STI classes lost their custom
> dataset definitions. Also, this is documented as: `You shouldn't call
> set_dataset in the model after applying this plugin, otherwise subclasses
> might use the wrong dataset.` in the docs.
>
> Is it possible to somehow use Sequel's sharding support to implement this
> read only console pattern, or is there a simpler solution that I am
> overlooking?
>
You could use the server_block extension, and wrap the code calling pry
with DB.with_server(:read_only){load_pry_cli_here}
Then when you wanted to operate on the default server, inside pry you could
do:
DB.with_server(:default){some_modification_operation}
Note that in general, any time that you make database schema changes
affecting Sequel models, any program that uses Sequel models should be
rebooted. Sequel models assume that the related database schema does not
change at runtime. So in pry for example, if you make a database schema
change affecting a model you have loaded into pry, you should be be
shutting down that pry session and creating a new one.
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.
