Yeah, your workaround of passing simpler data is IMO actually a best
practice. I have grown to hate DelayedJob's "feature" of serializing
whole class objects. Throwing it away in favor of simpler and more
reliable JSON is one of the best decisions Resque made.
One has not known true despair until one has stared into a Ruby 1.8->1.9
migration in which all the DelayedJob records will break because of
differences in the YAML parsers.
On Wed, Dec 17, 2014, at 05:08 PM, Ylan Segal wrote:
> Chris,
>
> I have been burned by the serialization / de-serialization issues in
> delayed job before. As a matter of fact, I have a shared spec for all my
> job classes that makes sure that makes sure that serialization and
> de-serialization work fine to try to find this before shipping.
>
> I usually have a shared example like:
>
> shared_examples 'a job implementation' do
> it 'can be serialized with Marshal' do
> expect {
> Marshal.load(Marshal.dump(subject))
> }.to_not raise_error
> end
>
> it 'can be serialized with YAML' do
> expect {
> YAML.load(YAML.dump(subject))
> }.to_not raise_error
> end
> end
>
> And then call that from in my job class specs:
>
> describe SomeJob do
> subject { SomeJob.new(whatever) } # Ensure you are setting up correctly
>
> it_behaves_like 'a job implementation’
>
> # Other tests for class go here.
> end
>
> Hope this helps,
>
> —
> Ylan Segal
> [email protected]
>
>
> > On Dec 17, 2014, at 4:55 PM, Chris McCann <[email protected]> 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 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 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.
>
> --
> --
> 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.
--
--
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.
