On 06/23/2011 08:46 AM, Chris Lalancette wrote:
On 06/23/11 - 12:43:40AM, Mo Morsi wrote:
src/app/models/instance.rb | 4 ++++ src/app/util/condormatic.rb | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/src/app/models/instance.rb b/src/app/models/instance.rb index 9c212d1..d32e820 100644 --- a/src/app/models/instance.rb +++ b/src/app/models/instance.rb @@ -130,6 +130,10 @@ class Instance < ActiveRecord::Base
before_destroy :destroyable?
- def after_find
- condormatic_instance_update(self)
- end
A few things here:
- From my very limited reading, after_find seems to get called for each
object in the list of found objects. Given our activerecord model, do we think this is sufficient? That is, could it ever be the case that we need to find by something like public_addresses, in which case this gets called too late?
The solution for this would be to override the find_by_state, find_by_public_addresses, etc methods to first query condor to find the matching instance id. We could provide a module to mixin to the Instance class so as to not clutter it up.
- How does this interact with solr/sunspot? It seems like what will happen
is that solr/sunspot can still do searches on the state field (for instance), but they may find "stale" states. Can we make it so that we do an update of that stuff before returning search results?
Looking at the source, sunspot_rails doesn't use the find_by_sql or conditions when running its queries so we should be fine on that front,
We do though in our app with the named scopes in instance. We could potentially override the find method in Instance to query condor, but this is a bit of work, and it might make more sense to use delayed_job to update the instances right in the app. It would be simpler and more fault tolerant than dbomatic, and good enough until we update the app to Rails 3 (we can use ActiveModel to tie the lifecycle of the instance closer to that of the condor job).
-Mo