Greg, thanks for pointing this out. I hope you know I'm doing my best to meet the standards required for an import. I don't think it's very nice to imply that I'm trying to avoid the hard work and just do the fun part. For this issue specifically I think your idea of updating the documentation to match your expectations would be best. That way future importers will know what will likely be expected. (Eg no foreign keys, etc. - Existing documentation seems to say that they are OK.)
On October 9, 2022 5:38:56 AM MDT, Greg Troxel <[email protected]> wrote: > >[email protected] writes: > >> * Handling future updates - Use UGRC:import_uuid tag to >> maintain a unique identifier back to the original database. Later when >> updating, skip rows with IDs that already exist. > >I'm really unclear on consensus about foreign keys. My impression is >that: > > 1) generally people on the list think they shouldn't be used, almost to > the point of rough consensus > > 2) everyone who is doing an import for the first time thinks they are > going to be useful later and wants to include them, even though the > first import is often "I only want to do the easy part" and none of > the difficult steps are implemented. > > 3) People who understand how difficult the difficult steps are don't > see any real value in foreign keys in the database. > >We have recent data for point 2 :-) > >Does anybody think I'm off base about (1) and (3)? If not, maybe we >should adjust the import guidelines to say "no foreign keys". If so, >maybe we should say "a single foreign key is ok". > >I don't think foreign keys are terrible, but I think they aren't that >useful and the combination of people not wanting to do the hard >matching/checking I recently outlined and wanting foreign keys is not a >good outcome -- we get the bloat without whatever benefit there might >be. >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
