This was fortuitous and probably why we didn't have a problem with the way it was when testing.
One other recursion we would want to stop: Saves from parent to child object. If you save a patient, the identifiers, names, and addresses all get a new ChangedBy and DateChanged. In https://tickets.openmrs.org/browse/TRUNK-3174 you propose @NoRecursion(handler=X.class). I can't think of much a better name. Maybe @DisableHandlers([X.class, Y.Class]) Ben On Thu, Mar 22, 2012 at 11:35 AM, Mark Goodrich <[email protected]> wrote: > Ben—**** > > ** ** > > I created a ticket for potential fix for this (TRUNK-3174).**** > > ** ** > > One question… it looks like Concept doesn’t have this problem with sets > and concept answers because set members and answer concepts are not store > directly as a Collection<Concept> on a Concept, but rather are connected > through an intermediate ConceptSet or ConceptAnswer type. Therefore, > assumedly (I haven’t tested this), when a concept is retired its associated > ConceptSets and ConceptAnswers are retired, but not the Concepts associated > with these ConceptSets and ConceptAnswers. This would be the functionality > we’d want in this case, but the only reason it would work is because > although the RequiredDataAdvice recursively handles child *collections*it > doesn’t appear to recursively handle child properties that aren’t > collections. (i.e., retiring a ConceptAnswer wouldn’t retire the > associated Concept property). Were things specifically designed this way, > or is this fortuitous happenstance?**** > > ** ** > > Mark**** > > **** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Mark > Goodrich > *Sent:* Wednesday, March 21, 2012 5:48 PM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] retiring/voided child collections when > retiring/voiding an object**** > > ** ** > > Yeah… so, what do you think the best solution would be? To create an > annotation you could add to a Collection in a domain object to specify that > retiring/voiding should not be propagated to that collection?**** > > ** ** > > Mark**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ben Wolfe > *Sent:* Wednesday, March 21, 2012 4:36 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] retiring/voided child collections when > retiring/voiding an object**** > > ** ** > > Looks like RequiredDataAdvice.recursivelyHandle has no provisions for > which collections it will or will not loop over. :-/ > > Ben**** > > On Wed, Mar 21, 2012 at 4:22 PM, Mark Goodrich <[email protected]> wrote:* > *** > > Ben,**** > > **** > > I’m creating a new “Provider Role” object (in a new Provider Management > module). This provider role has an associated set of provider roles > representing the other provider roles it can supervise, as well as an > associated set of relationship types that the provider role can support. > Neither of these should be retired when the parent provider role is > retired, but I discovered that they were when writing unit tests for the > new provider management service.**** > > **** > > Thanks,**** > > Mark**** > > **** > > **** > > **** > > **** > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ben Wolfe > *Sent:* Wednesday, March 21, 2012 3:36 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] retiring/voided child collections when > retiring/voiding an object**** > > **** > > Whats your object/mapping like that this is happening to? I can't think > of an example in openmrs. > > When first writing that I meant to go back and create an annotation to > allow for exceptions like this. However, I couldn't come up with a scenario > where it was needed, so kept putting it off. > > Ben**** > > On Wed, Mar 21, 2012 at 2:56 PM, Mark Goodrich <[email protected]> wrote:* > *** > > I see that the AOP that handles retiring/voiding a piece of Openmrs data > also automatically retires all child collections associated with that > object. This seems convenient and the right thing to do with one-to-many > relationships (ie, if you void an encounter, you want to void all its obs) > but does not seem to be the right thing to do if you have a many-to-many > relationship. Is there a proper way within OpenMRS to model many-to-many > relationships so that child collections of an object are not voided/retired > when the parent is retired?**** > > **** > > Thanks,**** > > Mark**** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > **** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
