Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.4-EDR1
    • Fix Version/s: 0.5
    • Component/s: API
    • Labels:
      None

      Description

      when writing on the spec this morning, I felt not satisfied, with our solutions how validities for currencies and regions were handled. Basically, with ValidityInfo and RelatedValidityInfo we already have a generalized solution for the return types. But the accessor methods were specific on the {MonetaryCurrencies}} and Regions singletons.

      Therefore I propose(in ext) an additional Validities singleton, which provides validities as required. But I still was not satisfied, since there were a lots of access methods that did more or less the same, just varying the input parameters a bit. Additionally we also support querying of legal tender related validities, which are different than the normal currencies per region relation. So I was looking for a more flexible solution and came to ValidityQuery, RelatedValidityQuery and ValidityType.

      The distinction what kind of ValidityInfo is required, I solved by adding a ValidityType value type. By default this is set to ValidityType.EXISTENCE, when a new ValidityQuery is created, but for legal tenders or other use cases may have different values, e.g. ValidityType.of("legalTender".

      Basically I see not many disadvantages, but many Advantages:

      • Validities are not constrained to currencies and regions anymore, also other types can be supported, by simply registering corresponding ValidityProviderSpi instances.
      • Queries can be extended, when useful (must be supported by the provider answering the query of course), so also very complex customer specific use cases can be modelled.
      • The client API is simple (4 methods only in tota).
      • Even bitermporal historization would be possible, by adding an additional parameter.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            atsticks
            Reporter:
            atsticks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1 day
              1d
              Remaining:
              Remaining Estimate - 1 day
              1d
              Logged:
              Time Spent - Not Specified
              Not Specified