Page Comparison

...

Sprint to extend some of the "read only" APIs, to finalize unit/integration testing for existing functionality, to extend the interface, to develop additional loaders, and to begin developing editing capabilities.

Fleshing out APIs

• Switch to a default build of the SAMPLE_2014AB and redo metadata and content tests against that data set.  Then we may be able to have more complete hierarchies and some code data to work withClients should handle null parameters properly
  
  • BAC: handle for content, metadata, project, security
  • Make a RootClientRest with a precondition check for null or blank
• Search should handle parse exceptions, e.g. if there are mismatched parens or braces, etc.
• Consider all query-based lookups in ContentServiceJpa and reimplement as lucene lookups instead if it seems that it would improve performance.
• Finalize REST service for a general concept query (e.g. lucene query, HQL query, or SQL query)
  • Must start with "SELECT " and not contain ";"
    
    • provide appropriate error message via exception if not
  • Execute the query but check the object type of the first result
    • if doesn't match expected type, fail with an exception.
  • Use timesout timeout = > 

  • query.setHint("javax.persistence.query.timeout", timeout);

  •  
• Implement NewConceptMinRequirementsCheck
  • Requires that a concept has at least one atom and one semantic type.
  • Create an integration (jpa) tests for the validation layer (e.g. put in spreadsheet, normal use, degenerate use, edge cases, etc).
    • It may be desirable to organize integration test packages by terminology (e.g. "com.wci....validation.umls" for UMLS checks ".snomed" for SNOMED checks, etc).
  • Implement the same check also for a SNOMED concept.
• Properly implement terminology remover functionality (e.g. content service rest.removeTerminology).  The content and the metadata objects need to be removed in the right order so as to avoid foreign key constraint errors. (e.g. attributes, definitions, semantic types, tree positions, transitive relationships, relationships, atoms, then atom classes - something like that).  For metadata I think terminology/rootTerminology is the only dependency (remove root terminology first).
  • Then update the mojo test case to remove the terminology (currently commented out)
• Implement SNOMED APIs
  • Model objects (in their own package)
  • jpa layer?

...

• Handler002Test for normal use
  • Needs implementation to test graph resolver for UMLS, SNOMED, and MSH cases.
  • Get objects from Jpa layer, test resolver does what we expect. 
• Implement Handler003/008Test - for ID assignment algorithms.  Borrow code from other project (though there may be differences).  The uuidHash algorithm is implemented properly for UMLS and may be different than for SNOMED.
• Content service integration test
  • normal use - see all of the "TODO" items indicating functionality that can be tested more fully that is not yet.
  • degenerate use
  • edge cases
• Better handle lucene searches like "xxx:yyy" where xxx is not a valid field name.  Should report that it is not a valid field name.

Editing Features

• Project
  • Figure out how to capture "project scope" for SNOMED and for UMLS in a generalized way.  Update project objects to be able to properly capture (and compute) project scope.  NOTE: the scope definition may involve concepts/terminologies/semantic types.  IN that event, the scope computer gets a little bit more complicated.
• Test loading a DB with envers auditing disabled and then making changes in a DB while it is enabled. Does it properly create audit entries?
  • for the old edition of the component?
  • for the new edition?
• Metathesaurus editing actions
  • MetathesaurusContentEditingRest
    • methods for each "edit action"
    • Create a RestImpl
    • Create a client
    • Create integration tests to run against a "stock" dev  database
  • Add a semantic type component, Remove a semantic type component
    • Have a pencil icon by  the STYs section
    • clicking gives you a list of available STYs assigned, in tree order with a filter box for typing characters of the STY you want.
      • See the metadata "semantic type" option
    • User may want to choose multiple ones (so have a "finished" button)
    • Dont allow user to choose STYs already assigned to the concept.
    • Final action is to call "contentService.addSemanticTypeComponent"
    • Consider what happens to workflow status
    • Consider how to show "NEEDS_REVIEW" content in the browser
    • Consider how to support "Undo". - perhaps an action log (atomic/molecular) is a good idea still for that
  • Implement this completely including testing before moving on to other actions (each which requires a UI enhancement)
    • Approve a concept (e.g. set workflow status values).
    • Add an atom (e.g. MTH/PN - that needs to be generalized somehow)
    • Merge two concepts (consider the "workflow status "when this happens).
    • Move an atom (or atoms) from one concept to another
    • Split an atom (or atoms) out of a concept and specify a relationship type between the two concept

...