Ben- This makes sense... thanks.
Mark From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe Sent: Friday, March 23, 2012 4:45 PM To: [email protected] Subject: Re: [OPENMRS-DEV] retiring/voided child collections when retiring/voiding an object 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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ben Wolfe Sent: Thursday, March 22, 2012 1:22 PM To: [email protected]<mailto:[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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Mark Goodrich Sent: Wednesday, March 21, 2012 5:48 PM To: [email protected]<mailto:[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]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Ben Wolfe Sent: Wednesday, March 21, 2012 4:36 PM To: [email protected]<mailto:[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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ben Wolfe Sent: Wednesday, March 21, 2012 3:36 PM To: [email protected]<mailto:[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]<mailto:[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<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[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]
