No, DM is untested as far as I know on Ruby 1.9, which again, as far as I know, Neverblock requires since it's just a Fiber based solution to concurrency.
Ok, let me re-phrase that. Fibers are GREAT. "Just" sounds dismissive. It's not. What I'm trying to say is that (again, as far as I know) Neverblock is _not_ an implementation of asynchronous API for Postgres. So it lets you run multiple connections concurrently. Good. It still blocks. That thread stalls until the database finishes up it's query execution. Just not the whole interpreter. So why is DM untested on Ruby 1.9? Simply because development is tight, and unless it comes from outside, I'm not personally putting in the effort to port to an unstable platform I don't actually intend to host production ready applications on. So what's the plan Sam? There's an Extlib issue around the pooling I need to work on. Once that's fixed DataObjects and Extlib 1.0 will both be released. They're both stable, and aside from this one issue, as far as I know, reliable. No good reason they shouldn't be 1.0, though I'd like to chat with the other Extlib authors/users before that release. Once DataObjects 1.0 is out, we'll begin work on 2.0 as we have time. 2.0 will support: * Named Parameters (exclusively, support for simple placeholders will be removed) * Asynchronous Query Support (the API will uniformly be updated, though not all the underlying drivers may actually support the feature; ie: Sqlite3) * Prepared Statements (this is more of a nice-to-have. Though depending on timing of the others, we might push it to 2.1 since it's fairly complex and will require customized, sized, LRU + statistical tracking collections that as far as I know nobody's written in Ruby yet) And that's it for Ruby 1.8.x obviously as we won't have native threads available to take full advantage of the Pooling or Asynchronous features. On JRuby, Rubinius and 1.9, as they become stable (and as we have time to implement), we plan to implement support in the Pooling module to allow for behaviour similar to Neverblock. The JRuby effort is waiting for either a JRuby champion to take on, or a Java client to request (and sponsor). Rubinius and 1.9 support is frozen until they have stable releases available. Adding support similar to Neverblock is a non-breaking addition, so unless someone anticipates using these platforms pre "1.0" (or 1.9.1 I suppose in the case of YARV), it seems reasonable that DM will offer no official specific support for Threading/Fibers on these platforms. I'm also not entirely sure that Fibers offer any advantages over a ThreadPool based system in conjunction with Asynchronous database drivers, so we'll probably stick to the ThreadPool solution once that support is in since having more fibers than actual threads and/or open connections obviously doesn't buy you a whole lot at the O/RM level (though you're certainly free to take advantage of them at the application level). So. If you're a champion who wants to make a real dent in what's possible with Ruby, and have some expertise writing multi-threaded code, get in touch and claim some work and we can accelerate the schedule. ;-) -Sam On Aug 26, 5:30 pm, weepy <[EMAIL PROTECTED]> wrote: > Hi > > I've just been reading about never block and their Active Record > plugin. > > http://espace.com.eg/neverblock/blog/2008/08/24/neverblock-and-active... > > Am I correct in thinking that DM already supports non-blocking access > to Postgrel in particular - so a Neverblock DM adapter is > unnecessary ? > > ;...( --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
