On Monday, February 27, 2017 at 1:05:34 PM UTC-8, Mike Pastore wrote: > > Hi Jeremy, > > I'd like to write a Sequel plugin/extension that modifies the behavior of > Sequel::Dataset such that it serializes the operation and passes it to a > callback instead of executing it. The goal is to be able to fire off > "asynchronous" queries a la ES/CQRS without deviating from the Sequel > dialect or shifting the logic to another process. For example: > > # register the callback somewhere (per model? at Sequel level?) > Sequel.register_async do |msg| > # write the "frozen" dataset (which may just be SQL?) to a message > queue, log file, or what have you > end > > # async is delegated to Foo.dataset? > Foo.async.where(:bar=>true).update(:qux=>false, :updated_at=>Sequel:: > CURRENT_TIMESTAMP) > > Later, some other Ruby process receives the message, establishes its own > database connection, and executes the dataset: > > DB << Sequel::Dataset.thaw(msg) > > Clearly this needs much more thought but I hope my intentions are clear > enough. I am planning to chip away at this using insert_sql, update_sql, > and delete_sql, capturing the emitted SQL as the "event," and passing that > along, but it may be somewhat cumbersome. > > - Do you know if anything currently exists to do something like this > within Sequel? My Googling has not been fruitful. > > I'm not aware of anything currently that does this or something similar.
> > - Do you have any thoughts on the best way to freeze/thaw a > Sequel::Dataset instance? Is capturing the emitted SQL good enough? > > There can be state other than the emitted SQL, at least in some cases. > - Any other implementation thoughts? Can you recommend a > plugin/extension I can crib from as an example? > > Sequel wasn't really designed for this. Instead of modifying Sequel to support this, you may want to consider building something on top of Sequel that does this instead. Alternatively, you may want to implement a custom adapter that does this. It is possible to implement what you want via an extension, at least in simple cases, but while the API may be nicer, it seems more likely to lead to implementation issues. 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.
