This is a bit complex, but I'll try to explain it as clearly as I can.
I'm using dynamic_storage to set up a set of storage locations in my system, which the user can add, remove, etc at runtime. The class that represents this is a Library in my system; each one has (is) a different Shrine storage.
There are items in the libraries that have attachments, and they automatically use the storage for the library that they're assigned to.
The problem comes with deletion. If we have a library with some items in, and we destroy it, the items also get destroyed using the normal rails dependent method.
However, after that is all committed and the items and library have been destroyed, the items in the library then call their after_commit hook:
|
model.after_commit on: :destroy do |
This hook tries to look up the storage location for the item (presumably in the attached? method, I've not delved inside that yet), which fails with a Shrine::Error saying the storage isn't registered. That's correct and expected, because the storage has been deleted; however, that after_commit hook doesn't handle the situation, so the error propagates up. I'm currently handling it by just discarding the error, but that feels a bit messy (manyfold3d/manyfold#3793)
I'm not sure what the right solution is here. Perhaps the after_commit hook should simply fail quietly if the storage isn't available any more? Or, maybe my blanket absorbing of errors on deletion is the best solution available. 😁
Any thoughts are most welcome... if there is a better way, I'm happy to do the work to improve it, but I'm not quite sure at the moment how to attack it.
This is a bit complex, but I'll try to explain it as clearly as I can.
I'm using
dynamic_storageto set up a set of storage locations in my system, which the user can add, remove, etc at runtime. The class that represents this is aLibraryin my system; each one has (is) a different Shrine storage.There are items in the libraries that have attachments, and they automatically use the storage for the library that they're assigned to.
The problem comes with deletion. If we have a library with some items in, and we destroy it, the items also get destroyed using the normal rails
dependentmethod.However, after that is all committed and the items and library have been destroyed, the items in the library then call their after_commit hook:
shrine/lib/shrine/plugins/activerecord.rb
Line 48 in 1ce6da4
This hook tries to look up the storage location for the item (presumably in the
attached?method, I've not delved inside that yet), which fails with a Shrine::Error saying the storage isn't registered. That's correct and expected, because the storage has been deleted; however, that after_commit hook doesn't handle the situation, so the error propagates up. I'm currently handling it by just discarding the error, but that feels a bit messy (manyfold3d/manyfold#3793)I'm not sure what the right solution is here. Perhaps the after_commit hook should simply fail quietly if the storage isn't available any more? Or, maybe my blanket absorbing of errors on deletion is the best solution available. 😁
Any thoughts are most welcome... if there is a better way, I'm happy to do the work to improve it, but I'm not quite sure at the moment how to attack it.