<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 8, 2020 at 11:30 AM Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

    
  
  <div>
    <p>Hi list,</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p><br></p></div></blockquote><div><br></div><div>Thanks for starting this discussions, we clearly need a path forward.</div><div><br></div><div>I just added a note on one of the topics (and cut the rest):<br></div><div> </div><div>[...]<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p><span id="gmail-m_-576102933281990865:ws.co" style="text-align:left" dir="ltr"><span id="gmail-m_-576102933281990865:ws.co" style="text-align:left" dir="ltr">* </span>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"</span>
    <p><span id="gmail-m_-576102933281990865:ws.co" style="text-align:left" dir="ltr">  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.</span></p>
    <p><span id="gmail-m_-576102933281990865:ws.co" style="text-align:left" dir="ltr">  Possible mitigation: offer a "repair" option in
        qgis. Through processing or "on the fly" upon detection.<br>
      </span></p></div></blockquote></div><div><br></div><div>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.</div><div> <br></div><div>This was IMHO a bad decision because it may turn a correct GPKG into a corrupted GPKG.</div><div><br></div><div>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.<br></div><div><br></div><div><br></div><div>Kind regards.<br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Alessandro Pasotti</div><div>QCooperative:  <a href="https://www.qcooperative.net" target="_blank">www.qcooperative.net</a><br></div>ItOpen:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div></div>