Uploaded image for project: 'CloverDX'
  1. CloverDX
  2. CLO-5961

Validator: IsDate rule strict mode

    XMLWordPrintable

    Details

    • Branch:
    • QA Testing:
      JUnit test
    • QA Test Identification:
      DateValidationRuleTest.testStrictParsing, ValidationIsDate_strict_CLO-5961.grf
    • Additional information:
      Hide

      Motivation: IsDate validation rule in previous versions wasn't strict enough and had to be supplemented by additional rules to function closer to "exact match" kind of rule that was sometimes needed. Let's look at an example.

      Imagine you want to validate that a bunch of input strings contain dates of pattern yyyyMMdd. You configure the pattern in the IsDate rule in Validator:

      After running the graph you notice that input string 2042074 is considered as valid date. But it has only 7 characters and the pattern you specified has 8. The validation rule is not strict enough.
      What you could do is add another validation rule to check that the input strings have length of exactly 8 characters since that is the length of your validation pattern:

      That solves the problem but it will be annoying to work with - every time you'll edit the rules you'll have to remember that the length rule is there to supplement the date rule.
      Now there is a better solution. The IsDate rule has a new property called Strict validation. When you switch it to true the rule will perform additional check during the validation. It will make sure that the validated string matches the validation pattern exactly:

      Another example is string 2015-001-012 and pattern yyyy-MM-dd. Here we specified that the month and day elements of the date can only contain two digits, however the input date contains three digits instead. The default IsDate rule considers the input as valid but the strict validation does not since it's not exact match.

      Here's how the validation actually works for this case when you set strict validation to true:

      1. Parse the input string 2015-001-012 using pattern yyyy-MM-dd to a Date object.
      2. Format the Date object to another string using the same pattern. That results in a string 2015-01-12.
      3. Compare the original and formatted strings. Since 2015-001-012 and 2015-01-12 are not the same the original string is considered as invalid date.

      Project with these two examples and all the rules configurations is available in this archive: ValidatorStrict.zip

      Show
      Motivation: IsDate validation rule in previous versions wasn't strict enough and had to be supplemented by additional rules to function closer to "exact match" kind of rule that was sometimes needed. Let's look at an example. Imagine you want to validate that a bunch of input strings contain dates of pattern yyyyMMdd . You configure the pattern in the IsDate rule in Validator: After running the graph you notice that input string 2042074 is considered as valid date. But it has only 7 characters and the pattern you specified has 8. The validation rule is not strict enough. What you could do is add another validation rule to check that the input strings have length of exactly 8 characters since that is the length of your validation pattern: That solves the problem but it will be annoying to work with - every time you'll edit the rules you'll have to remember that the length rule is there to supplement the date rule. Now there is a better solution. The IsDate rule has a new property called Strict validation . When you switch it to true the rule will perform additional check during the validation. It will make sure that the validated string matches the validation pattern exactly: Another example is string 2015-001-012 and pattern yyyy-MM-dd . Here we specified that the month and day elements of the date can only contain two digits, however the input date contains three digits instead. The default IsDate rule considers the input as valid but the strict validation does not since it's not exact match. Here's how the validation actually works for this case when you set strict validation to true : Parse the input string 2015-001-012 using pattern yyyy-MM-dd to a Date object. Format the Date object to another string using the same pattern. That results in a string 2015-01-12 . Compare the original and formatted strings. Since 2015-001-012 and 2015-01-12 are not the same the original string is considered as invalid date. Project with these two examples and all the rules configurations is available in this archive: ValidatorStrict.zip

      Description

      Note that the length of the pattern may differ from the length of the input.
      The length should be checked for individual parts separately.

      At least the documentation should be updated to warn the user:

      For parsing, the number of pattern letters is ignored unless it's needed to separate two adjacent fields.

      http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html

        Attachments

        1. highlight_step1_problem.png
          highlight_step1_problem.png
          50 kB
        2. highlight_step2_old_solution.png
          highlight_step2_old_solution.png
          64 kB
        3. highlight_step3_new_solution.png
          highlight_step3_new_solution.png
          51 kB
        4. validace_datumu.grf
          22 kB
        5. validator_compare_after.png
          validator_compare_after.png
          69 kB
        6. validator.png
          validator.png
          63 kB
        7. ValidatorStrict.zip
          6 kB

          Issue Links

            Activity

              People

              Assignee:
              salamonp Pavel Salamon
              Reporter:
              krivanekm Milan Krivanek
              Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 3 hours
                  3h