5 ms·

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

• mbs348 12y ago
  Yes, exactly. It is an interesting/cool idea to create an object URI to make this possible!
• joevandyk 12y ago
  You do GlobalID.locate(gid) in the job.
  • DouweM 12y ago
    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#globalid-support https://github.com/rails/rails/tree/master/activejob#globali...
• swanson 12y ago
  Yes - there is a good example on the ActiveJob README (https://github.com/rails/activejob#globalid-support https://github.com/rails/activejob#globalid-support).
• sync 12y ago
  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.
  • damncabbage 12y ago
    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#globalid-support https://github.com/rails/rails/tree/master/activejob#globali... for an example.)
  • DouweM 12y ago
    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 https://github.com/rails/activejob/issues/25 The discussion was then continued here: https://github.com/rails/rails/pull/16485#discussion-diff-16273182 https://github.com/rails/rails/pull/16485#discussion-diff-16..., which is where the `ActiveJob::DeserializationError` comes from.
• hayksaakian 12y ago
  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.
  • DouweM 12y ago
    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#globalid-support https://github.com/rails/rails/tree/master/activejob#globali...
    • hayksaakian 12y ago
      Is it? I assumed it worked like delayed_job which gave me issues due to the problem I mentioned.
      • DouweM 12y ago
        It is! That's the exact problem ActiveJob+GlobalID tries to solve.
        • hayksaakian 12y ago
          I suppose I was mistaken then, thanks for helping me understand.
      • volkk 12y ago
        why bother spreading false information without even taking a minute to read into what it actually does?