Closed alexprengere closed 11 years ago
That sounds a very good idea :)
Please, do not forget that ori_por is a generated file. Hence, the modifications will be lost at the next update from OpenTravelData.
I would suggest, in a first easy step, just to create a patch file, which would then be sent by mail, and/or attached to an automatically created issue. Indeed, Geonames does not allow updates through its Web Services (WS), which would have been very convenient otherwise...
With 5f031638d67eb56daaad1b9cce58fb012cfafcd1, this works fine with delimited fields. This means that if you change the value of a delimited field (a tuple
), then save the results, the file will be updated. Sub-delimiters should be consistent with those used during data loading.
Note that if you modify a raw version of a delimited field, like tvl_por_list@raw
, changes will not be saved, since these fields are not dumped by default.
Idea
From the Python API, be able to save changes made with
set
, in the initial loaded file (if any).Example for a normal base
This way the
ori_por
file would be updated with the newORY
name, and would have a new line for the entrynew_por
.Example for a base without initial file
The mechanism can be a bit tricky for bases without regular initial file like
feed
, so we should be able to do something like this, where we explicitely define everything:Since
g.fields
are not automatically updated when data is set, this may be a good opportunity to useg.syncFields()
to synchroniseg.fields
with the underlying data. If we resume he previous example:Conclusion
I implemented a draft of this specification in the
develop
branch. Comments/ideas are welcome!