In #225 we found that currently all occurrences for the same rule need to be generated from the same *Validator class.
For optimization purposes, some of W009 checks for stop_time_updates were implemented in StopTimeUpdateValidator, while the checks specific to trips were implemented in TripDescriptorValidator. However, this currently causes problems when the *Validator classes are executed in BackgroundTask, as each class inserts a set of occurrences for the rules into the database, which caused a duplicate entry for occurrences of W009 (instead of all W009 occurrences properly being inserted in a single entry). Moving all checks for the same rule into the same class was the workaround solution implemented for W009 in 3bca917.
In the future we should examine allowing more than one Validator class to check for the same rule, which would require modifications to BackgroundTask to combine occurrence lists from multiple Validator classes before they are inserted into the database.
Steps to reproduce:
Have more than one Validator class generate occurrences for the same rule (for example W009 - revert this commit 3bca917).
Expected behavior:
The tool should log all occurrences correctly no matter what *Validator class generates them
Observed behavior:
If more than one *Validator class generates occurrences for the same rule, it results in more than one database record for that rule for a given iteration, which results in duplicate iterations being shown in the Log and IterationDetails page, and an invalid timestamp value of 1970... - see #225 for details.
Platform:
Windows 7 Enterprise w/ jdk1.8.0_73 and Chrome Version 58.0.3029.110 (64-bit)
Issue by barbeau Jan 14, 2017 Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/226
Summary:
In #225 we found that currently all occurrences for the same rule need to be generated from the same *Validator class.
For optimization purposes, some of W009 checks for stop_time_updates were implemented in StopTimeUpdateValidator, while the checks specific to trips were implemented in TripDescriptorValidator. However, this currently causes problems when the *Validator classes are executed in BackgroundTask, as each class inserts a set of occurrences for the rules into the database, which caused a duplicate entry for occurrences of W009 (instead of all W009 occurrences properly being inserted in a single entry). Moving all checks for the same rule into the same class was the workaround solution implemented for W009 in 3bca917.
In the future we should examine allowing more than one Validator class to check for the same rule, which would require modifications to BackgroundTask to combine occurrence lists from multiple Validator classes before they are inserted into the database.
Steps to reproduce:
Have more than one Validator class generate occurrences for the same rule (for example W009 - revert this commit 3bca917). Expected behavior:
The tool should log all occurrences correctly no matter what *Validator class generates them
Observed behavior:
If more than one *Validator class generates occurrences for the same rule, it results in more than one database record for that rule for a given iteration, which results in duplicate iterations being shown in the Log and IterationDetails page, and an invalid timestamp value of 1970... - see #225 for details.
Platform:
Windows 7 Enterprise w/ jdk1.8.0_73 and Chrome Version 58.0.3029.110 (64-bit)