On Fri, May 8, 2020 at 11:30 AM Matthias Kuhn <[email protected]> wrote:
> Hi list, > > I wondered about the state of GeoPackage. Personally, cince it has been > introduced to qgis and evenmore since it has been selected as the default > format, I have never grown to fully and completely. > > I do not want to trigger a evangelical discussion here. I'd like to see > where we are and what we can reasonably do to have a default file format > which can be recommended with no bad feelings. > > > Thanks for starting this discussions, we clearly need a path forward. I just added a note on one of the topics (and cut the rest): [...] > * The couple of corrupted files I have received over the years which > could only be repaired by a command line "dump contents as sql and execute > into new file" > > I have not found a way to reproduce this. Some of them were produced by > older qgis versions making it easy to violate foreign key constraints and > hard to recover. This has been fixed. > > Possible mitigation: offer a "repair" option in qgis. Through processing > or "on the fly" upon detection. > If I'm not mistaken, the fix was to disable foreign key constraints altogether for the whole QGIS application for all GPKGs, no questions asked. This was IMHO a bad decision because it may turn a correct GPKG into a corrupted GPKG. A better approach in case of corrupted files would have probably been to disable foreign constraints only in case a file is corrupted and restore the constraints after the file has been repaired or, as you already mentioned to offer an automatic or semi-automatic repair function. Kind regards. -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
