We have moved a part of our Rails app into a “service”, i.e. a Ruby
script that is demonized and communicates with the main app through a
message queue.
This service needs to know about the models in the Rails app, but it
does not need a database connection. Indeed, we are making sure that
in this service, no call to the DB will be made.
How would you do that? At the moment, we are simply requiring the
models files in the service. But since they inherit from
ActiveRecord::base, it won’t work if there is no connection to a DB
available.
models files in the service. But since they inherit from
ActiveRecord::base, it won’t work if there is no connection to a DB
available.
Thanks!
Pierre
Not sure if the approach is applicable to your situation without knowing
more but if you run the script via runner (starting it from the app
root,
it will have access to the Rails environment, including your models.
we pass to our “service” the Model objects (we Marshal.dump them in
the main app, enqueue them, and the service Marshal.load them) instead
of their unique ID.
in the service, we just need to access some of the models’ methods.
We know these methods don’t need a DB connection.
The reason we have it setup like this is initially, we were running
these tasks in threads within a background job (threads caused a bunch
of issues when we were using the DB, so we made sure what we passed to
the threads would never use the DB).
Bill: we run this service completely independently, on a different
box. So it does not have access to the app.
we pass to our “service” the Model objects (we Marshal.dump them in
the main app, enqueue them, and the service Marshal.load them) instead
of their unique ID.
in the service, we just need to access some of the models’ methods.
We know these methods don’t need a DB connection.
Do you need knowledge of any of the attributes of the object that are
database fields? If so then you need a connection to the db as it is
by looking in the db that the model knows what its fields are and
hence the attribute names.
The reason we have it setup like this is initially, we were running
these tasks in threads within a background job (threads caused a bunch
of issues when we were using the DB, so we made sure what we passed to
the threads would never use the DB).
As Bill has suggested in his reply, you could extract the methods that
do not need the database (if they really do not) out into helpers.
The reason we have it setup like this is initially, we were running
these tasks in threads within a background job (threads caused a bunch
of issues when we were using the DB, so we made sure what we passed to
the threads would never use the DB).
Bill: we run this service completely independently, on a different
box. So it does not have access to the app.
Maybe we should not be doing something like this?
If the methods don’t need access to the DB, then the question is do they
need access to the AR object? Or are they being passed the data they
need
to work on as arguments? If the latter, then they’re more ‘helpers’ and
could be re-factored out into a module to be included in the model and,
independently, in the service. If that doesn’t sound feasible, post
some
code so we can see better what you’re doing.