On Fri, Apr 16, 2010 at 2:17 PM, Brian Takita <[email protected]> wrote: > On Fri, Apr 16, 2010 at 1:48 PM, Jeremy Evans <[email protected]> wrote: >> On Apr 16, 1:09 pm, Brian Takita <[email protected]> wrote: >>> Yeah, I'll have to see what the implications are. >>> The major problem I'm having right now is Friendly does not play nice >>> with Rails transactional fixtures, and test speed is important to me >>> (and my coworkers). >>> I don't want to start a debate over whether fixtures are good or not. >>> For us, they are good. >> >> I think you'll have problems in most cases. Quite a few Sequel >> adapters modify the underlying connection objects in order to produce >> desired behavior, and ActiveRecord's connection is not going to be >> completely compatible in those cases. >> >> Also, I'm not sure how using the same connection for Sequel and AR >> will solve any problems in terms of test speed or transactions. Does >> Friendly not work because it uses Sequel and Rails' transactional >> fixtures only work with the ActiveRecord connection? Because fixing >> that is as simple as modifying the test runner (e.g. >> http://github.com/jeremyevans/fixture_dependencies/blob/master/lib/fixture_dependencies/test_unit/sequel.rb). > I just realized that the bug lied elsewhere. I changed the type of the > foreign key from integer to string and did not update the Friendly > document. So I misdiagnosed it as a transaction issue. > > The only time this would not work is when doing joins from AR to/from > Friendly. I don't intend to do this, so it should not be necessary to > share the object. I meant joins in sql. > > Anyways, I made something slightly more robust, as long as the app is > single threaded. However, I'm going to delete it now, since it is not > necessary. :-) > > Friendly.db.meta_def(:connect) do > unless ActiveRecord::Base.connection.active? > ActiveRecord::Base.reconnect! > end > ActiveRecord::Base.connection.raw_connection > end > >> >>> > Honestly, just use separate connections for Sequel and AR. You'll >>> > have fewer problems that way. >>> >>> Another reason for this is connection management. We do quite a bit of >>> forking (Nginx Passenger and forked workers). It would be preferable >>> to manage only one connection, or object. >>> I suppose some sort of connection manager object could be set up which >>> integrates with Sequel's connection (and pooling?) and ActiveRecord, >>> however just using the same object seems like the simplest thing for >>> us at this point. >> >> For anything with forked workers, you should be disconnecting all >> database connections before the fork, and reconnecting after. Doing >> this for both ActiveRecord and Sequel is many times simpler than >> trying to make them both use the same connection object and just >> trying to disconnect that connection object. > That makes sense. I can see how there could be issues, however in a > single threaded environment, >> >>> I'll keep you posted on how it turns out. >> >> Please do. >> >> An alternative solution would be to use Sequel::Model instead of >> ActiveRecord. Then you don't have to worry about sharing connections, >> plus you get all of the benefits Sequel::Model brings over >> ActiveRecord. Of course, if you have a lot of existing ActiveRecord >> code, I can see where this may be an issue. > Interesting. I'll take a look at Sequel::Model. >> >> Jeremy > Thanks for putting up with my fumbling, > - Brian >> >> -- >> 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. >> >> >
-- 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.
