You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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).
The text was updated successfully, but these errors were encountered:
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
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).
The text was updated successfully, but these errors were encountered: