Reservation generator hard-fails in seeds script

[shippy]

Currently, the seeds script stops if the Reservation generator creates an object that fails validation. This usually happens for two reasons:

• A previously generated Blackout occurs during start or end date of the Reservation
• A previously generated Reservation overlaps with the currently generated object

The probability of validation failure increases with the number of Reservations and Blackouts generated.

There are two possible solutions. I favor the second.

1. Write Reservation-generating logic that will prevent conflicts
2. Wrap the current Reservation-generating logic in a begin..rescue ActiveRecord::RecordInvalid { continue } block, which ignores the error but allows the seeds script to continue.

Thoughts?

[mnquintana]

(2) is a good stopgap, but we really should have Reservation-generating logic that never fails validations (especially since Reports depends on this to be accurate, which could make debugging Reports in the future next to impossible).

[dgoerger]

Does it save the validations-failing records to the database? It shouldn't, and if it doesn't, that shouldn't affect reports at all. I agree however that Approach One is preferable.

[shippy]

@dgoerger: It doesn't save the records to database.

I disagree. To write up a logic that produces a valid reservation is to completely duplicate the validations logic we have. It's much faster - and more elegant - to make use of it: generate records fully randomly, catch the exception whenever they fail validations (and thereby are not saved), and go on generating until we have the right number of valid objects.

[orenyk]

I agree with @shippy on this one, we've designed our validations to ensure we only save valid Reservations, so let's make use of that functionality here as well. It seems like the DRY solution to me.

[dgoerger]

I only suggest approach one is preferable, because an admin running the seed script will expect a certain number of generated records. If some fail, we should then output that in the terminal script so the admin knows why numbers don't add up.

[orenyk]

Oh that's fair. There must be a way to try again rather than simply skip it.

[shippy]

redo/retry should do that.

[shippy]

Right now, the Reservation-generating logic is in seeds.rb:486-528. First, it generates all Reservation records with times in the future; then, it takes up to 75% of thus generated records and updates them with attributes in the past. (Relevant code: to_fling_into_the_past = reservation.sample(rand((entered_num / 4)..entered_num)))

Both these blocks should probably be wrapped in begin .. rescue blocks, with the rescue block including a retry instruction.

[orenyk]

This is pretty well hashed out, putting it in v4.0.

[orenyk]

On second thought, bumping to v4.1 to clear out v4.0.