This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Query For Change Requests matching multiple states

DRAFT - this scenario is currently under development

Scenario

This scenario is derived from the CmOfRequirements scenario.

For purposes of conflict detection, a Requirements application may need to query for change requests of varying states such as:

  • assigned or review query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true
  • assigned, review or approved query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true OR oslc_cm:approved=true
  • assigned, review, approved or applied query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true OR oslc_cm:approved=true OR oslc_cm:closed=true
  • assigned or approved query
    oslc_cm:inprogress=true OR oslc_cm:approved=true
These queries are necessary because a requirements application may allow users to propose changes that are conflicting and needs to provide a way for those conflicts to be identified and resolved. Allowing the user to filter on the state of the change request allows for maximum flexibility in determining the scope of proposed changes checked during conflict detection. The user may choose to only look for conflicts in change requests that have been approved, or may decide that it would be better to also check for conflicts with change requests that are currently in progress or under review (fixed).

Pre-conditions:

  • CRs to query

Post-conditions

  • no change

Specification needs

Add a new property to the Change Request resource

Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_cm:predicate zero-or-many True String n/a

approved

closed

fixed

inprogress

reviewed

verified

Provides a single property containing all applicable predicates. When retrieving properties of a change request, this overlaps with the individual state predicate properties and adds no value. However, when used as part of a query with the oslc.where parameter it lets the consumer efficiently filter the query results to find change requests matching more than one of the available predicates.

For example, oslc_cm:predicate in ["inprogress", "fixed"]

Alternatives:

  • Adding a simple general "OR" support
    • adds complexity of grouping
    • possible to use a simplified "OR"? doesn't deal with precendence order or grouping.
  • Run separate queries, client joins - This is the only alternative possible using the existing OSLC-CM 2.0 spec
  • Specialized query capabilities

Resources

  • ChangeRequest - as-is
Edit | Attach | Print version | History: r8 | r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 22 Jun 2011 - 21:41:14 - BrianSteele
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback