The issue in this particular case is that the :before_destroy callback
fires off an asynchronous background task that needs data from the object
being deleted in order to do its thing. That ActiveRecord model object has
been destroyed by the time the background task executes, so DB lookup isn't
an option.
Here's what I ended up using, in case someone else finds themselves in the
same situation:
# a callback to delete 3rd party recognition
# service target information. Having to pass in
# an OpenStruct because DJ doesn't seem to be able
# to properly deserialize a deleted object
def destroy_recognition_targets
src_image = OpenStruct.new(id: self.id, target_id: self.target_id)
Delayed::Job.enqueue RecognitionTargetDestroyerJob.new(src_image)
end
Using OpenStruct here leaves the code in the Job unchanged in terms of
reading the object attributes, such as:
src_image.target_id
Also, one of the DJ maintainers on Github closed the issue I opened, as
shown here. I don't disagree with his logic.
delayed_job issue #753
<https://github.com/collectiveidea/delayed_job/issues/753>
On Thu, Dec 18, 2014 at 10:59 AM, Richard Bishop <[email protected]>
wrote:
>
> I'm just here to 2nd/3rd/4th/5th/whatever not relying on
> serialization/deserialization of Ruby objects into databases and message
> queues. Stick to integers and then do a find.
>
> On Wednesday, December 17, 2014 5:55:26 PM UTC-7, Chris McCann wrote:
>>
>> SD Ruby,
>>
>> I'm using delayed_job_active_record 4.0.2 in a Rails 4.1.5 app. I came
>> across some behavior in DJ that I think is a bug but would like other
>> opinions.
>>
>> My app pushes data to two third-party services, so when the related
>> ActiveRecord object is deleted data related to the deleted object needs to
>> be cleaned up. This is a perfect task for a background job.
>>
>> I have a before_destroy callback on the SourceImage object:
>>
>> before_destroy :destroy_recognition_targets
>>
>>
>> And the callback looks like this:
>>
>> Delayed::Job.enqueue RecognitionTargetDestroyerJob.new(src_image)
>>
>>
>> The problem I found is that DJ fails when it tries to deserialize the
>> data that's serialized as YAML in the job's :handler field (you can see it
>> in the database). Since it can't deserialize the object the job just hangs
>> (I would expect an actual error to be thrown, but that's another issue).
>>
>> There was a Github issue
>> <https://github.com/collectiveidea/delayed_job/issues/587> posted about
>> this that was closed. I've added a new one.
>>
>> Can anyone attest to whether this used to work in DJ? It seems to me
>> that it did, and the linked issue above seems to say the same.
>>
>> FYI, the workaround I put in place was to just pass the relevant
>> attributes to the DJ job via an OpenStruct, and that works fine.
>>
>> Cheers,
>>
>> Chris
>>
> --
> --
> SD Ruby mailing list
> [email protected]
> http://groups.google.com/group/sdruby
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "SD Ruby" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sdruby/k7mYlGDoaWI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google Groups "SD
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
