One negative to calling the LogicService with just a token name (and not referencing the RuleProvider) is the possibility of token name conflicts. We ran into this issue because there was a default Logic birthdate token, but we also had our own token named birthdate as well. When our token was registered, it was just given a new token name of “birthdate 2”. The problem was we did not know this happened until we tried to use our birthdate rule, and we weren’t getting the expected results back. It was actually evaluating the default Logic birthdate rule instead or ours. I would suggest if we only get a rule by token name, we make it a unique field and throw some type of exception if someone tries to register a token with the same token name as a pre-existing one.
Steve From: [email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin Sent: Monday, November 14, 2011 8:56 PM To: [email protected] Subject: Re: [OPENMRS-DEV] The future of Logic Can we enumerate what we want from the simplified logic service? * Existing logic engine can be implemented as an optional module without too much trouble. * Strongly instead of loosely typed results. * Support for parameters. * ... Do we want to support an index date (i.e., avoid assuming today's date)? Don't we want to forego tokens? Or are we assuming that consumers of logic know which rule provider to consult (which may or may not use tokens)? If the consumer needs to know which provider to consult and that provider will presumably be handling the evaluation, then what purpose does the logic service serve? Alternatively, rule providers could be registered with the logic service and then consumers could come to the logic service with a token (i.e., not need to know the provider). I'm assuming that we'll defer caching & criteria implementations to the various forms of logic (at least for now). What's the purpose of LogicContext now? In the original design, LogicContext served a few purposes: (1) proxy for all data requests by rules, (2) provide a context for evaluations – index date & parameters – that could be stacked for recursion, (3) context for caching results, and (4) an abstraction so that the same rule could be run against a patient or cohort. If we aren't using logic context for any of these, do we need to maintain LogicContext at this stage? Looking forward to the design call. Cheers, -Burke On Wed, Nov 9, 2011 at 10:23 PM, Michael Seaton <[email protected]<mailto:[email protected]>> wrote: Hi all, I wanted to pick up a thread on the future of Logic that we spent some time discussing during the Developers Forum on October 27<https://wiki.openmrs.org/x/5oamAQ>. The overall consensus on the call was that "Logic is too complicated. We wish there were a simpler implementation, that were easier to adapt to individual needs. We wish it were more rigorously tested, including performance testing". Anyone that cares about preserving Logic as it currently exists, or wants to see it change in a specific way, please read further Specific users of Logic have communicated the following needs: * Tammy and her team require more control over the current Logic implementation, and better testing around it, so that future upgrades do not cause serious bugs and performance degradation * Win and Tammy need implementations of Logic that are optimized for running lots of rules for individual patients at a time * Mike needs an implementation of Logic that is optimized for running a single rule for lots of patients at a time as well * Mike wants to be able to choose to not use the existing Logic implementation in favor of an implementation provided by the Reporting module To accomplish this, the following high-level refactoring steps are being considered: * Reduce and simplify the number of interfaces and interface methods that Logic exposes in OpenMRS core * De-couple the existing Logic Module in such a way that it is one of many possible "Rule Providers" that can plug into this lighter-weight core framework * Remove, if possible and practical, the need to have a "required" Logic module installed Specifically, we are considering an approach that would reduce the core Logic interfaces to something like: interface LogicContext; interface Result; (classes DateResult, NumberResult, ListResult...) interface Rule { Set<RuleParameterInfo> getParameterInfo(); Class<? extends Result> getReturnType(); Result evaluate(Integer patientId, Map<String, Object> parameters, LogicContext context); } interface LogicService { public Result evaluate(Rule rule, Patient patient, Map<String, Object> parameters, LogicContext context); public Map<Integer, Result> evaluate(Rule rule, Cohort cohort, Map<String, Object> parameters, LogicContext context); } I would like for this to spur the following potential activities: * Give anyone who has not yet been aware of these discussions, or who does not agree with this approach, an opportunity to weigh in and get involved in the process * Make a plan to put this topic onto one or more future Design Forum calls, in order to agree upon the revised design, make tickets, and establish an owner for moving it forward. * Publicize when this Design Forum will occur so that interested parties can be involved as desired Thanks! Mike ________________________________ 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
