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