Deferrables would certainly help towards the goal of clean code using one of the extant blocking ORMs (datamapper, activerecord, sequel), but it doesn't actually satisfy the need for achieving parallelism (see here for an excellent explanation of why: http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/).
I think that Jeremy may be right, and I should start to tackle building a nonblocking ORM from the ground up. Sigh. Thanks for your prompt replies! On Nov 18, 3:55 pm, Chuck Remes <[EMAIL PROTECTED]> wrote: > On Nov 18, 2008, at 2:13 PM, Jeremy Evans wrote: > > > > > On Nov 18, 9:36 am, None <[EMAIL PROTECTED]> wrote: > > >> Any ideas? Anyone else out there need anything like this? > > > Not really. If you can spawn threads to deal with the database > > interactions, and just check those threads to see if they have > > completed (and get the data they return if they have), it might be > > possible to use Sequel in your nonblocking app. Sequel shouldn't > > block the entire ruby interpreter unless the underlying database > > driver does (ruby-pg and postgres-pr do not, but ruby-mysql does). > > I'm not sure that is possible in ruby though, or if event machine > > allows it (and if it did, you could put any blocking code in it, not > > just Sequel). > > In Eventmachine you would use EM::Deferrable for all of your Sequel > calls. EM would handle spawning any ruby threads (green threads in > MRI, native threads in JRuby). Then use #set_deferred_status in the > Deferrable to notify your business logic when the Sequel calls have > completed. > > cr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to sequel-talk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
