TheTransitClock / transitime

TheTransitClock real-time transit information system
GNU General Public License v3.0
79 stars 30 forks source link

storeNewRevs command line switch unexpected behaviour - seems to affect all configRev values, not only ActiveRevision ones #269

Open BodoMinea opened 1 year ago

BodoMinea commented 1 year ago

Expected functionality I would expect that running GtfsFileProcessor without setting the storeNewRevs option on the command line would import the given GTFS with an incremented configRev value but not update ActiveRevisions so that I could do that at a later time (eg. for importing a future version of the feed and switching to it when it becomes current).

Describe the bug Running GtfsFileProcessor without setting the storeNewRevs option attempts import the given GTFS feed as configRev '0' as opposed to the next configRev version, even if configRev '0' already exists (resulting in a failing import due to duplicate key entries).

To Reproduce Import an initial version of a GTFS feed using GtfsFileProcessor. After that, import an updated one both with and without storeNewRevs on the command line. The import that lacks storeNewRevs will import as configRev 0, while the one with storeNewRevs will import with the next available configRev number and also update it in ActiveRevisions.

Screenshots image

Additional context This is happening in a multi-agency environment, the config file which references the hibernate file is given as a parameter on the command line. This is happening without setting an explicit configRev as a command line parameter (eg. it is unset or set to -1, which according to the comments in the code should make it such that imports increment configRev automatically).