Skip to content

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

@BodoMinea

Description

@BodoMinea

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions