<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Alessandro,</p>
<p>Thanks for pointing that out.<br>
</p>
<div class="moz-cite-prefix">On 5/8/20 11:51 AM, Alessandro Pasotti
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL5Q671c3+hinZxpvbewzYsbvw3MhvpM_MrMdu5tBk=YTi_f-w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><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"
moz-do-not-send="true">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>
</blockquote>
<p><br>
</p>
<p>The old situation was: it's possible to change a value without
checks. It's not allowed to open a broken gpkg. I.e. easy to
break, impossible to recover.</p>
<p>The new situation is: It's possible to open a broken gpkg, so
it's possible to recover).</p>
<p>There may be space for further improvements on the "editing"
side. This needs to be carefully tested (i.e. make sure it plays
well with deferred checks, like on postgres, and incomplete
transactions are fully rolled back without entering into a broken
state of gpkg again).</p>
<p>Bests<br>
</p>
<p>Matthias<br>
</p>
</body>
</html>