You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up as a "I expected this to work!" kinda thing, and am curious about your opinion on the matter.
A long explanation of the issue
# example adapted from http://guides.rubyonrails.org/association_basics.html#choosing-between-has-many-through-and-has-and-belongs-to-manyclassAssembly < ActiveRecord::Baseacts_as_archivalhas_many:manifests,dependent: :destroyhas_many:parts,through: :manifests,dependent: :destroyendclassManifest < ActiveRecord::Baseacts_as_archivalbelongs_to:assemblybelongs_to:partendclassPart < ActiveRecord::Baseacts_as_archivalhas_many:manifests,dependent: :destroyhas_many:assemblies,through: :manifests,dependent: :destroyend
In this situation, Assembly and Part can be archived separately, and either will correctly archive the Manifest connecting them. But that doesn't represent the ideal for a situation in which a Part is archived after a Manifest connected to it is archived, since they will have different archive_numbers. Here is some demonstrative code:
assembly=Assembly.createpart=Part.createmanifest=Manifest.create(assembly: assembly,part: part)assembly.archiveassembly.archived?# => truemanifest.archived?# => truepart.archivepart.archived?# => truepart.archive_number == manifest.archive_number# => false # starting to see a problem!assembly.unarchivemanifest.archived?# => falsepart.archived?# => truemanifest.unarchived.joins(:parts)# => [manifest] # oops!
So, this will now return a set of Manifests that includes an archived Part, which is technically correct but perhaps logically incorrect.
Solution
A thing that comes to mind: change the schema to allow multiple archive_number columns.
Note the actual code is going to be a lot more meta, but this is effectively a way to achieve this, and “easily” extends to 3+-way associations.
Another thing to consider is surfacing (through documentation) the internals of the archiving modules so that they can be derived from more easily to make custom archived? statuses easier to achieve. I don't know if that's a good idea, but certainly in non-trivial situations there is not much guidance in the repo itself for how to deal with multi-way conditional archiving - and may be it should remain that way. I htink explaining the philosophy behind this tool further might help, though. This is a solution to 90%+ of archiving problems, but the other 10% is murky. It's important to know that your application can override any of our internal bits to work within the application. Like ARec itself, this is often not needed, but ARec does a reasonable job of being like "it's okay. sometimes we aren't perfect and you need to use raw sql or do some transactions in a service or whatever" #Rambles.
The text was updated successfully, but these errors were encountered:
@esquivalient @stevegrossi
This came up as a "I expected this to work!" kinda thing, and am curious about your opinion on the matter.
A long explanation of the issue
In this situation,
Assembly
andPart
can be archived separately, and either will correctly archive theManifest
connecting them. But that doesn't represent the ideal for a situation in which aPart
is archived after aManifest
connected to it is archived, since they will have differentarchive_number
s. Here is some demonstrative code:So, this will now return a set of
Manifest
s that includes an archivedPart
, which is technically correct but perhaps logically incorrect.Solution
A thing that comes to mind: change the schema to allow multiple
archive_number
columns.Which would allow us to do something that is effectively:
Note the actual code is going to be a lot more meta, but this is effectively a way to achieve this, and “easily” extends to 3+-way associations.
Another thing to consider is surfacing (through documentation) the internals of the archiving modules so that they can be derived from more easily to make custom
archived?
statuses easier to achieve. I don't know if that's a good idea, but certainly in non-trivial situations there is not much guidance in the repo itself for how to deal with multi-way conditional archiving - and may be it should remain that way. I htink explaining the philosophy behind this tool further might help, though. This is a solution to 90%+ of archiving problems, but the other 10% is murky. It's important to know that your application can override any of our internal bits to work within the application. Like ARec itself, this is often not needed, but ARec does a reasonable job of being like "it's okay. sometimes we aren't perfect and you need to use raw sql or do some transactions in a service or whatever" #Rambles.The text was updated successfully, but these errors were encountered: