It seems that the only real solution so far is "roll your own". Thanks for the help!
On Nov 18, 3:13 pm, Jeremy Evans <[EMAIL PROTECTED]> wrote: > On Nov 18, 9:36 am, None <[EMAIL PROTECTED]> wrote: > > > Forgive me if this is a naive question. I has noobie. > > > I'm developing a scalable distributed back end search system for a > > client, and using eventmachine to great effect thus far. However, we > > need database access, and that's where things start to get sticky. > > > I can use em-mysql and mysqlplus to make async db queries, but I'd > > like to use an ORM to keep the code clean and simple. ActiveRecord is > > a poor fit, from what I can tell so far. It has a blocking API, and > > offers little hope of straightforward modification to fit the async io- > > driven design of eventmachine. > > Sequel's database connection API is blocking as well, and there are no > plans to change it to make it non-blocking. While non-blocking code > can have higher performance, it's generally more difficult to write > and therefore more error prone. > > > I'm wondering if there's an entry point / layer in the Sequel stack > > that would allow me to say (in effect): Here is a row from by > > database, please create Model Foo from it for me. > > If you want to pull records from the database yourself and create > models from them, it's pretty easy: > > Model.load(hash) > > > 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). > > The last nonblocking app I wrote was in Python, and it did use SQLite > as a backend, but only as a persistence layer since everything was > also stored in memory. I created a database thread that read from a > shared queue. So the nonblocking code would put any changes to > persist on the queue (which didn't block), and the database thread > would read from the queue and persist the changes (when it got around > to it). It would block when reading from the database, but since it > only needed to do so at startup (to store everything in memory), that > wasn't an issue. Obviously, if you need to read data from the > database in a nonblocking manner (and can't store everything in > memory), you can't do that. > > The best way to use Sequel in a nonblocking application would be to > create a nonblocking connection pool and a nonblocking database > adapter. Those should the only parts of Sequel that are blocking. > However, most of the other code is written with blocking in mind, so > you will probably run into other issues. > > Honestly, you would probably be better off trying to create your own > ORM that was nonblocking, borrowing good ideas you see in the other > ORMs you want to emulate. Unless being nonblocking is part of the > initial design, it is very difficult to retrofit. > > Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
