This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Query recursion"
Jump to navigation
Jump to search
Ian.townend (talk | contribs) |
|||
| Line 7: | Line 7: | ||
:recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... [[User:Rene spronk|Rene spronk]] 11:19, 15 Jun 2006 (CDT) | :recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... [[User:Rene spronk|Rene spronk]] 11:19, 15 Jun 2006 (CDT) | ||
| + | |||
| + | Are there other options? I would agree that a new "blue" relationship would be the better way | ||
| + | to go. COMP was only used to demonstrate the kind of functionality we were talking about as | ||
| + | people will be familiar with it. | ||
:You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do. Of course, if you remove the nesting, as you show in your choices, then you can't nest - that's what you are saying. But you can just leave things as they are in the RIM, and there's no issue? Or have I missed something? [[User:Grahame Grieve|Grahame Grieve]] 18 Jun 2006 (CDT) | :You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do. Of course, if you remove the nesting, as you show in your choices, then you can't nest - that's what you are saying. But you can just leave things as they are in the RIM, and there's no issue? Or have I missed something? [[User:Grahame Grieve|Grahame Grieve]] 18 Jun 2006 (CDT) | ||
| + | |||
| + | Yes, you can nest using LogicalExpression but you have to explicitly model what level of nesting | ||
| + | is required. We can't say any way of doing it dynamically. We don't know how many levels of | ||
| + | nesting will be required so can't model it explicitly. How can this dynamic method be done | ||
| + | currently? Remove the nesting?? | ||
Revision as of 09:07, 19 June 2006
Within the Choose and Book domain of the NHS CFH project, a requirement has been identified to allow dynamic recursion of queries. The topic was raised at the HL7 UK Infrastructure meeting on June 14th, 2006 and the consensus of those present at that meeting was that the current query mechanism is not sufficiently flexible to do what Choose and Book message designers need it to do.
A Query Modelling Presentation was given at the UK Infrastructure meeting, and includes a summary of the business requirements, an explanation of why we believe the current mechanism doesn't work, and our proposed solution - namely introducing the concepts of choice boxes and recursion to the query mechanism in order to dynamically process nested queries (examples are given in the presentation).
Comments/questions/suggestions on regarding this modelling problem are requested and would be gratefully received either here on the Wiki or via the message lists.
- recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... Rene spronk 11:19, 15 Jun 2006 (CDT)
Are there other options? I would agree that a new "blue" relationship would be the better way to go. COMP was only used to demonstrate the kind of functionality we were talking about as people will be familiar with it.
- You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do. Of course, if you remove the nesting, as you show in your choices, then you can't nest - that's what you are saying. But you can just leave things as they are in the RIM, and there's no issue? Or have I missed something? Grahame Grieve 18 Jun 2006 (CDT)
Yes, you can nest using LogicalExpression but you have to explicitly model what level of nesting is required. We can't say any way of doing it dynamically. We don't know how many levels of nesting will be required so can't model it explicitly. How can this dynamic method be done currently? Remove the nesting??
