I don't think we should add recursion to child objects. That was an intentional choice. 99% of the time the child object is the "many" side of a "many-to-one" and so should not be modified (Creator, ChangedBy, Concept on ConceptAnswer, etc). The fortuitous happenstance was that we had ConceptAnswer and ConceptSet as go-betweens on the Concept object so that set members and answers weren't automagically retired when the parent was retired.
If we added that in there, all openmrs objects and module objects would have to annotate themselves saying recursion shouldn't happen. I could see having it the opposite though, only recurse to an OpenmrsObject property if @EnableHandlers was set on it. (but List<OpenmrsObject> properties still recurse by default) Ben On Fri, Mar 23, 2012 at 3:57 PM, Mark Goodrich <[email protected]> wrote: > I like @DisableHandlers… I’ve added that suggestion to the ticket.**** > > ** ** > > Should we enter a second ticket for modifying RequiredDataAdvice so that > it operates on child OpenmrsObjects (and not just child collections of > OpenmrsObjects)? This would be a more significant change than TRUNK-3174 > and it would break the “fortuitous” way concepts works… but it seems like > it would be more consistent and is worth considering. This isn’t critical > to what I’m trying to do, which is good, because it seems too significant a > change to backport. I could enter a ticket for it and then we could get > feedback from Burke and Darius when they are back from their travels?**** > > ** ** > > Take care,**** > > Mark**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ben Wolfe > *Sent:* Thursday, March 22, 2012 1:22 PM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] retiring/voided child collections when > retiring/voiding an object**** > > ** ** > > 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 > **** > > ** ** > ------------------------------ > > 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]
