Trigger before save and after save from external process?

[Jeff]

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?

[Walter Lee Davis]

On Mar 27, 2014, at 11:16 PM, Jeff 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?
>

No. You would have to have some sort of timed process pinging the database for changes, and that's a stupid idea anyway -- think race conditions! The filters all run in Ruby, and without loading and executing your changes within the Rails environment, they will never "know" that anything happened in the database. They will only see the new values when they next load the objects from the database.

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.

Walter

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/739482be-f47b-441b-ba98-c6e07f848b55%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hassan Schroeder]

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

[Rick]

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.

[mike2r]

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

agree with the data integrity concerns.  if it's possible, I think the API solution above is the best option.  It is possible to write a batch invocation of ActiveRecord which your external process would have to call, but I think the cleanest way to insure all the before/after filters are executed is by building an API.  

If you're going to hit the database directly, at least push your model constraints back into the database so that integrity is maintained.  That still potentially leaves an issue with your before/after filters.  For example, if you have an after filter that writes to a log/audit file after a transaction is saved, that won't get executed.  Again, API would be the cleanest and consistent with the way systems interface to each other.

[Jeff]

What do people who use SequelPro (and related tools) do to trigger their action filters usually?

Writing an API sounds ideal but what if you have little control over the tool.

[Frederick Cheung]

On Saturday, March 29, 2014 3:43:32 PM UTC, Jeff wrote:

What do people who use SequelPro (and related tools) do to trigger their action filters usually?

Writing an API sounds ideal but what if you have little control over the tool.

If your after filters only do db changes then you may be able to use a trigger (possibly using something like postgres' notification events). Other than that you can't detect arbitrary changes to your database (and even using triggers, those could in general be altered/disabled by this hypothetical person using sequel pro)

Fred