<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/12/2015 07:13 PM, Alex M wrote:<br>
    </div>
    <blockquote cite="mid:5644C8B8.50002@wildintellect.com" type="cite">
      <pre wrap="">Yes we should implement a cheat in QGIS (core) to handle this issue.
Other SQLite GUIs do this. Spatialite GUI and SQLite Manager (Firefox
plugin).

The basic process:
1. Make a new table the way you actually want it.
2. SQL INSERT records from Old to New (Mapping old columns to new if
name changed).
3. Remove old table
4. Rename new table to old name
5. Vacuum to recover extra pages allocated in the shuffle.

Nothing else should be needed, since you use the same name, spatial
indexes and geometry_column records should stay the same unless the
Geometry column is renamed.

This method will apply to both GeoPackage (If editing is allowed),
Spatialite tables, and any non-spatial sqlite tables.

-Alex</pre>
    </blockquote>
    <br>
    One caveat: if foreign keys, or views are defined (the reasons for
    using a spatialDB in the first place) pointing to a column in the
    table to be reshuffled, this process fails. Since sqlite does not
    have any "DROP CONSTRAINT" then you have to start renaming the other
    dependent tables also...<br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:5644C8B8.50002@wildintellect.com" type="cite">
      <pre wrap="">

On 11/12/2015 04:30 AM, Matthias Kuhn wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">The main issues with spatialite are IMO: It's based on sqlite so
deleting columns and renaming columns is not supported by design. We
could offer some hacks to bypass this (annoying restriction) from the UI
- there is a risk of side effects though. Another property of it is,
that it's already 4-5MB big, even when empty. I consider this a major
limiting factor as well. Other issues which we were not yet able to
solve are its management of the information scheme which keep duplicate
entries of tables and columns which need to be properly updated which we
apparently do not manage (yet).

Geopackage is also based on sqlite, so the column delete/rename
restrictions apply as well (with the same workaround possibilities). I
haven't checked the file size, but if that's smaller, that would be
quite nice (does somebody know?).

All the best
Matthias
_______________________________________________
Qgis-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-user">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>

</pre>
      </blockquote>
      <pre wrap="">

This mail was received via Mail-SeCure System.


</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <div dir="LTR">
        Micha Silver<br>
        Arava Drainage Authority<br>
        +972-523-665918
      </div>
    </div>
  </body>
</html>