Ruby on Rails

The easiest way to have an external process run within your application context is to write your external app in ruby and run it inside a call to rails runner ... . You pay a penalty at startup but gain access to your application's environment (think rails console).

There is nothing inherently wrong with having multiple clients working out of the same database tables. The complications come when more than one client tries to modify the same field in the same record at the same time. Two strategies come to mind.

First, you can use roles (db_mgr and db_user) to restrict access to 'troubling' actions. You would require all change activity (create/update/delete) to be done only by db_mgr. Database tables could then be managed by your offline application.

Second, you can bring your application to a reduced state - don't forget to notify users - and manage your tables while the database is quiet.



On Friday, March 28, 2014 8:47:24 AM UTC-4, Hassan Schroeder wrote:

On Fri, Mar 28, 2014 at 5:00 AM, Walter Lee Davis <wa...@wdstudio.com> wrote:

>> I have an external process changing the database of my app. Is there a good way to trigger the before save and after save filters for models that get updated, when it is an external process changing it?

> Try to think more about your overall application architecture. Maybe your "external process" can call an API in your Rails app instead of changing the database directly, behind its back.

+1 - this scenario has "data integrity fail" stamped all over it.

If you can't avoid having the external process write to the db, at least
have it write to *non-model* tables and incorporate the updates from
there (via periodic rake task, or whatever).

Good luck.
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan