Trigger before save and after save from external process?

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?

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

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 Fri, Mar 28, 2014 at 5:00 AM, Walter Lee D. [email protected]
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 S. ------------------------ [email protected]
http://about.me/hassanschroeder
twitter: @hassan

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

changing the database directly, behind its back.
http://about.me/hassanschroeder
twitter: @hassan

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.

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.

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs