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:
1) 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.
2) 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