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 -~----------~----~----~----~------~----~------~--~---
