Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strict Matching #29

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Strict Matching #29

wants to merge 5 commits into from

Conversation

meesterdude
Copy link
Contributor

This PR adds strict matching to cron parsing.

I find the default matching behavior when both DOW and DOM are specified to be unexpected. It inhibits a number of use cases, like matching Friday the 13th, or the second tuesday in a month (when i have philly.rb meetings!). So, I added an optional flag to support "strict matching" where both DOM and DOW must match.

Added spec coverage for behavior, and updated Readme to reflect. Happy to discuss any changes or make additional ones to get this merged in.

@meesterdude meesterdude mentioned this pull request Mar 20, 2016
@siebertm
Copy link
Owner

Hey Russell,

First of all: thanks for looking into that issue!

I aggree with your thinking that one should be able to express friday the 13th, but the spec itself doesn't allow this (as far as I can see).

Your idea of switching the "new" behaviour (why did you call it strict? Can't find that anywhere) with a flag looks sound to me.

I'll add general feedback to the code directly in the code.


def set_strict_match(strict_match = false)
@strict_match = false
if strict_match && [time_specs[:dom].last, time_specs[:dow].last].all?{|v| v != '*'}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that check even needed? I mean if the user tells us to use strict matching, why would we refuse that? I'd rather do:

  attr_accessor :strict_match
  alias_method :strict_match?, :strict_match

This would even get rid of the predicate method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually yes; when I did not have this check in place, other specs failed that should not have. I'll admit I only 60-70% get whats actually going on with the code, so maybe you'd know better than I why. or, maybe it was from something else I later undid. I'll see what happens when i remove it again.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I just notifed when reading through the whole file that this beast is in serious need of a refactoring.

My plan yould be to chunk it up into understandable pieces, like having a CronParser::Default and CronParser::Strict class. But for that, lots of code would need to be changed, so I would do that after incorporating your changes.

@meesterdude
Copy link
Contributor Author

@siebertm thanks for reviewing this! much appreciated.

I called it "strict" because it's a strict match. But you're right, it's made up. this is outside of the cron spec, but behavior that I wish it could do, instead of what it does now which I doubt anyone has ever actually used, because its a weird match condition to rely on.

@meesterdude
Copy link
Contributor Author

@siebertm i updated the PR to remove the inverted if blocks. As for the removal of the check, and using attr_accessor, I was unable to get that to work sanely. It really does need to only be strict when both are wildcard, any other condition, with it enabled, can result in weird behavior.

Sorry for the long turn around! Let me know if there's anything else I need to update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants