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
Currently the RDBMS validator will check for duplicate primary keys (e.g., stop_id in stops.txt) and duplicate compound keys composed of a string and an integer (e.g., trip_id + stop_sequence in stop_times.txt), but there is no way to check for duplicate keys that are composed of two strings. One such case where this omission could lead to logically incoherent results is for transfers.txt where two lines containing the same from_ and to_stop_id pair would be invalid (there may be some strategy that GTFS consumers use to prioritize one record over the another that I'm not aware of). Another similar case is duplicate lines in fare_rules.txt, e.g., two rows that contain the exact same information. Such an occurrence would be caught in stops.txt because of the duplicate primary key (on stop_id), but there is no primary key for this table and so a fare_rules table with 10 of the same duplicated row would throw no errors.
This has been somewhat addressed already in #200 with the addition of the hasCompoundKey method, but it does not fully account for proper storage of these errors because the error table expects an int for this value, not a String.
The text was updated successfully, but these errors were encountered:
Currently the RDBMS validator will check for duplicate primary keys (e.g., stop_id in stops.txt) and duplicate compound keys composed of a string and an integer (e.g., trip_id + stop_sequence in stop_times.txt), but there is no way to check for duplicate keys that are composed of two strings. One such case where this omission could lead to logically incoherent results is for transfers.txt where two lines containing the same
from_
andto_stop_id
pair would be invalid (there may be some strategy that GTFS consumers use to prioritize one record over the another that I'm not aware of). Another similar case is duplicate lines infare_rules.txt
, e.g., two rows that contain the exact same information. Such an occurrence would be caught instops.txt
because of the duplicate primary key (onstop_id
), but there is no primary key for this table and so a fare_rules table with 10 of the same duplicated row would throw no errors.This has been somewhat addressed already in #200 with the addition of the
hasCompoundKey
method, but it does not fully account for proper storage of these errors because the error table expects anint
for this value, not aString
.The text was updated successfully, but these errors were encountered: