Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • core code that does
    • dependency tree calc of sources
    • determine query order and potential for parallelism, probably better to figure it with always parallel and having "block" spots that wait for other sources to complete
    • caching of results from each source
    • handling of query timeouts
    • merging results from various sources
    • mapping attribute names from the API side to the SPI side
      • TODO move this into a transformation API
    • jmx metrics for per-source usage & performance
    • primaryId
      • Used when a find person by primary id query is run
      • Used to merge data from multiple sources (each result must have a primaryId set)
  • add a list of AttributeSourceFilter
    • these are called in order (sorted by ordered)
    • if any filter returns false the filtered source is not executed
    • filterchain style API that allows for modification of search?
  • dependency tree calculation on configured attribute sources
    • needs to fail to init if something is wrong with the tree
    • this probably needs to be calculated and cached for each query since the tree will look different every time based on the input
  • caching of results - part of XML config support
    • for each configured source, set cache name or reference to Ehcache bean
    • optional cache name/ref for misses
    • optional cache name/ref for exceptions
  • query timeout - part of XML config support
    • set maximum wait for query result
    • set behavior on timeout? (ignore, fail)
  • merge behavior - part of XML config
    • does it work for each source to have a "prepend/append/overwrite" flag?
    • if so we probably need support for Spring's Orderable on the SPI implif two sources return different attribute values for the same attribute ignore the second and log an error
  • attribute name mapping - part of XML config support
    • for each configured source, option to allow for saying api attr "username" is actually "uid" in this spi
    • which direction does this mapping work?
  • attribute lists
    • in the config are these the PD side or the source side of the attr mapping?
    • at least one required or optional search attribute must be specified
    • required search
      • ALL of these attributes must be include in a query for this source to be able to run the query 
    • optional search
      • This plus the required set make up the collection of attributes that can be used to search, attributes outside this set are ignored
    • available return 
      • The list of attributes the source returns, this is a best-effort set and the source may return more attributes than are named in the set

...