Package wt.vc.config

Interface ConfigSpec

All Superinterfaces:
Externalizable, Serializable
All Known Implementing Classes:
wt.vc.config._AbstractChangeConfigSpec, _AsMaturedConfigSpec, _ATORuleConfigSpec, wt.vc.config._BaselineConfigSpec, wt.vc.config._ChangeConfigSpec, wt.eff._EffConfigSpec, _EffConfigSpecGroup, _EffectivityConfigSpec, wt.epm._EPMDocChangeConfigSpec, _EPMDocConfigSpec, _InUseConfigSpec, wt.vc.config._IteratedFolderedConfigSpec, _LifeCycleConfigSpec, wt.lotbaseline._LotBaselineConfigSpec, wt.eff._PersistableEffConfigSpec, wt.part._PlantEffConfigSpec, wt.part._PlantEffConfigSpecGroup, wt.part._PlantEffectivityConfigSpec, wt.vc.config._PlantLifeCycleConfigSpec, wt.part._PlantPersistableEffConfigSpec, _PlantStandardConfigSpec, wt.maturity._PromotionNoticeConfigSpec, _ViewConfigSpec, _WTDocumentConfigSpec, _WTDocumentStandardConfigSpec, _WTPartAsMaturedConfigSpec, wt.part._WTPartBaselineConfigSpec, wt.part._WTPartChangeConfigSpec, _WTPartConfigSpec, _WTPartCustomConfigSpec, _WTPartEffectivityConfigSpec, wt.part._WTPartPromotionNoticeConfigSpec, _WTPartStandardConfigSpec, wt.vc.config.AbstractChangeConfigSpec, AsMaturedConfigSpec, ATORuleConfigSpec, AuthoringApplicationConfigSpec, BaselineConfigSpec, BaselineConfigurationConfigSpec, Changeable2ConfigSpec, ChangeConfigSpec, ConfigurationVisitor, EffConfigSpec, EffConfigSpecGroup, EffectivityConfigSpec, EPMAsStoredConfigSpec, EPMDocChangeConfigSpec, EPMDocConfigSpec, ESIDefaultConfigSpec, InUseConfigSpec, IteratedFolderedConfigSpec, LatestConfigSpec, LatestReleasedConfigSpec, LifeCycleConfigSpec, LotBaselineConfigSpec, MultipleLatestConfigSpec, MultipleOwnershipIndependentLatestConfigSpec, OwnershipIndependentLatestConfigSpec, PersistableEffConfigSpec, PlantEffConfigSpec, PlantEffConfigSpecGroup, PlantEffectivityConfigSpec, PlantLatestConfigSpec, PlantLifeCycleConfigSpec, PlantPersistableEffConfigSpec, PlantStandardConfigSpec, PromotionNoticeConfigSpec, RemoveConfigurationVisitor, SandboxConfigSpec, SerialNumberedConfiguredInstanceConfigSpec, SharedOnlyConfigSpec, ViewConfigSpec, WorkspaceConfigSpec, WTDocumentConfigSpec, WTDocumentStandardConfigSpec, WTPartAsMaturedConfigSpec, WTPartBaselineConfigSpec, WTPartChangeConfigSpec, WTPartConfigSpec, WTPartCustomConfigSpec, WTPartEffectivityConfigSpec, WTPartPromotionNoticeConfigSpec, WTPartStandardConfigSpec
public interface ConfigSpec extends Externalizable
Implementations of this interface are used by the ConfigService to convert Mastered objects into Iterated objects based on some existing QuerySpec. Due to the nature of the master to iteration relationship in the database most but not all of the selection work can be done in the database; some of the work must be done after iterations are retrieved from the database.

A ConfigSpec has two key methods: appendSearchCriteria(wt.query.QuerySpec) adds to the database query specification that iterations must meet and process(wt.fc.QueryResult) does post-query filtering required to finally determine the appropriate iteration(s). Because no assumptions are made as to whether or not the iterations to process are "latest" iterations, the query criteria becomes especially important.

ConfigSpec usage:

When creating new ConfigSpecs it is important to document carefully what both key methods do. Usually reuse is achived by delegation rather than inheritance, so it is likely that one or both of the key methods in a ConfigSpec may be reused. In particular if one of the key methods does nothing, then that should be noted.

Supported API: true

Extendable: true

See Also:

  • Method Details

    • appendSearchCriteria

      QuerySpec appendSearchCriteria(QuerySpec querySpec) throws WTException, QueryException
      Appends to the supplied QuerySpec additional search criteria to reduce the resulting iterations to only those that will be considered by this ConfigSpec. Appending additional classes to the QuerySpec is allowed (for join purposes), but those that are marked as selectable will be trimmed by "filteredIterationsOf" prior to it calling the "process" API.

      The QueryResult returned should be a copy of the passed in one (taking advantage of side-effects is not encouraged).



      Supported API: true
      Parameters:
      querySpec - A QuerySpec with a target class that is Iterated.
      Returns:
      QuerySpec
      Throws:
      WTException
      QueryException
      See Also:

    • process

      QueryResult process(QueryResult results) throws WTException
      Process the QueryResult of iterations, returning only those that "match" according to the algorithm.

      The QueryResult returned should be a copy of the passed-in QueryResult (side-effects should be avoided).



      Supported API: true
      Parameters:
      results - QueryResult of iterations to filter. Assumed to be the result of a query that included the additional search conditions applied by appendSearchCriteria. Note that after enumerating through the elements of this QueryResult, it should be reset.
      Returns:
      QueryResult
      Throws:
      WTException
      See Also:

    • getRelationalConfigSpec

      Object getRelationalConfigSpec() throws WTException
      Returns the ConfigSpec to use when relationalizing this config spec. This is either a ConfigSpec or a RelationalConfigSpec. A relatianalized config spec utilizes the database (via appendSearchCriteria(QuerySpec)) to remove the need to post-process the QueryResult using process(QueryResult).

      Typical return values are:

      • null if the config spec can not/does not support moving everything to the database
      • this if the config spec itself supports relationalization
      • a RelationalConfigSpec (such as the RelationalConfigSpecBridge) which wraps the existing config spec to move processing into the database.

      Note: It is discouraged to return null as config specs that don't support relationalization can not be used by straight-query implementations. For example, it is possible to navigate the WTPartUsageLink and the other side iterations in one database hit by applying a relational config spec; a non-relational config spec would need to navigate to the master in one hit and then resolve the masters to iterations in a second, followed by post-processing to remove unnecessary iterations.

      Supported API: true

      Returns:
      null if the ConfigSpec does not support relationalization, otherwise a config spec that does
      Throws:
      WTException - anticipates the case where factory methods needlessly throw WTExeception