-
Notifications
You must be signed in to change notification settings - Fork 57
Fundamental Rewrite of Validation System #644
Conversation
squidgetx
commented
Jul 8, 2014
- Moving all 'soft' validations to cart validations instead of reservation validations. This enables the cart to run most validations only one time instead of for every equipment model in the cart (available, renewable, duration, max cat count, max model count, reserver has overdue, blackout dates)
- Reservation.validateSet is no more
- Only necessary validations run when the dates are updated and when items are added/removed (doesn't check for blackout dates when adding a new item to cart, for instance)
This is almost done. Still need to go over the ReservationsController spec |
# Checks that reservation is not in the past | ||
# Does not run on checked out, checked in, overdue, or missed Reservations | ||
def not_in_past | ||
unless due_date >= Date.today |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about the start date?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I was thinking that a reservation with a start date in the past and due date in the future is still 'active', but not_in_past runs only on 'create' and should check the start date as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it shouldn't matter since start_date_before_due_date would trigger in the case that the due date is before Date.today and the start_date wasn't. Since in that case its not clear whether or not that reservation was intended to be made in the past or not it would be clearer to leave out not_in_past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right! Good catch yourself :-)
def get_items | ||
# Used in cart_validations | ||
# Return items where the key is the full equipment model object | ||
# uses 1 database call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like that you've been documenting when you're making DB calls, let's try to make that the case across our codebase. It will not only be good for documentation purposes but could also potentially uncover some other inefficiencies.
I'm getting the spec failures on my local build (freshly checked out the EDIT: I agree with @shippy, this work is fantastic :-)
|
WOO HOO! Great job! |
return false if reqs.include?(em_req) | ||
end | ||
return true | ||
#binding.pry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please delete this, even though it's commented out. :-P
# Checks that reservation is not in the past | ||
# Does not run on checked out, checked in, overdue, or missed Reservations | ||
def not_in_past | ||
if due_date < Date.today |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to also check for start_date < Date.today
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check the discussion on oren's first diff comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One still shouldn't be able to create a reservation with a start_date
in the past.
Fundamental Rewrite of Validation System