Hacker News Reader

Comment by tvon | Hacker News Reader

So GlobalID means instead of doing `SomeJob.enqueue(instance.id)` (and then `Model.find(id)` in the job) you just do `SomeJob.enqueue(instance)`, and presumably reference something like `object` in the job?

View on HN

Yes - there is a good example on the ActiveJob README (https://github.com/rails/activejob#globalid-support).

We frequently ran into the issue of the object having been deleted while sitting in the job queue, so Model.find(id) would blow up. I'd be curious to hear if GlobalID did anything about that.

This won't do anything for you there; it just collapses a Class and a record ID down into a string for you (and then pulls it back out of your database later with a GlobalID::Locator.locate(string) call).

It's not full-record-serialization, and it can't bring back deleted records for you.

(See https://github.com/rails/rails/tree/master/activejob#globali... for an example.)

We had a bit of a discussion about that, finally settling on adding `rescue_from` which you'll know from ActionController and raising a `ActiveJob::DeserializationError` wrapping `ActiveRecord::RecordNotFound`, allowing you to handle this lookup failure however you see fit.

See the original discussion here: https://github.com/rails/activejob/issues/25

The discussion was then continued here: https://github.com/rails/rails/pull/16485#discussion-diff-16..., which is where the `ActiveJob::DeserializationError` comes from.

You do GlobalID.locate(gid) in the job.

That's incorrect. The global ID sent along the wire is transparently looked up at deserialization.

See the example here: https://github.com/rails/rails/tree/master/activejob#globali...

Yes, exactly. It is an interesting/cool idea to create an object URI to make this possible!

Beware, this behavior lets you shoot yourself in the foot because when you conduct your job, you might be working with a stale object that's changed since the job went on the queue.

That's incorrect. This is not YAML-style full object serialization, but rather a global ID being sent along the wire that is transparently looked up at deserialization.

See the example here: https://github.com/rails/rails/tree/master/activejob#globali...

Is it? I assumed it worked like delayed_job which gave me issues due to the problem I mentioned.

It is! That's the exact problem ActiveJob+GlobalID tries to solve.

I suppose I was mistaken then, thanks for helping me understand.

why bother spreading false information without even taking a minute to read into what it actually does?

Reply on news.ycombinator.com