Validate start/end when scheduling queries

[betodealmeida]

CATEGORY

Choose one

• Bug Fix
• Enhancement (new features, refinement)
• Refactor
• Add tests
• Build / Development Environment
• Documentation

SUMMARY

This PR adds validation to start and end dates when scheduling queries in SQL Lab, ensuring that the end date doesn't come before the start date.

It also initializes the form with defaults. Ideally we want these to be relative dates, so I used the Sugar library to parse human readable dates. For example, with this config:

            'start_date': {
                'type': 'string',
                'format': 'date-time',
                'title': 'Start date',
                'default': 'today at 9am',
            },
            'end_date': {
                'type': 'string',
                'format': 'date-time',
                'title': 'End date',
                'default': '9am in 30 days',
            },

We get:

TEST PLAN

Tested locally:

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

REVIEWERS

@DiggidyDave @khtruong @datability-io

[codecov-io]

Codecov Report

Merging #7508 into lyft-release-sp8 will decrease coverage by 0.07%.
The diff coverage is 4%.

@@                 Coverage Diff                 @@
##           lyft-release-sp8   #7508      +/-   ##
===================================================
- Coverage             65.27%   65.2%   -0.08%     
===================================================
  Files                   435     435              
  Lines                 21389   21414      +25     
  Branches               2357    2361       +4     
===================================================
+ Hits                  13961   13962       +1     
- Misses                 7308    7332      +24     
  Partials                120     120

Impacted Files	Coverage Δ
...sets/src/SqlLab/components/ScheduleQueryButton.jsx	9.09% <4%> (-4.25%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4bddc6...fc8670a. Read the comment docs.

[khtruong]

I thought we already had some logic or a library that handles relative dates. I am a little iffy about using this library because it looks like it's maintained by one developer and the last version was 5 months ago so I am not sure how often this library is maintained.

[betodealmeida]

@khtruong we use moment.js, but it can't parse relative dates like these, which is what we really want.

[khtruong]

Still a little iffy about using the Sugar library but if you felt that it was the best that suits your needs, I trust ya.

[betodealmeida]

@khtruong yeah, I understand your point. I found another library called chrono which does the same and depends only on moment.js, I'll use that instead.

[betodealmeida]

TBH, I don't think the time-of-last update is a good factor for determining if we should use a library. Some libraries are small, do one thing, and do it well, and no longer need to be updated at some point. But Sugar does more than one thing, and it has many dependencies, so even if we're using it for something that might never change (date parsing) it might break in the future if its dependencies change.

Chrono, on the other hand, does only one thing (date parsing), and only depends on moment.js, which we also depend on, so I think it's a safer bet. I'll update this PR in a bit.