[QGIS-Developer] Status of transaction support in Geopackages

[Nyall Dawson]

On 28 February 2018 at 06:40, Alessandro Pasotti <apasotti at gmail.com> wrote:
> On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli <luipir at gmail.com> wrote:
>>
>> >
>> > On 27/02/2018 11:12, Mark Johnson wrote:
>> >>>> that we get rid of the current provider and rely on GDAL only.
>> >>
>> >> With the 'current provider' I assume you mean the Spatialite-Provider.
>> >>
>> >> Please remember that the Spatialite-Provider was never designed to
>> >> support GeoPackage.
>> >>
>> >> Please also remember that Gdal/Ogr does not support all aspects of
>> >> Spatialite
>> >> - writable SpatialViews are not supported
>> >>
>> >> The present QgsOgrProvider does not support Spatialite-Tables with more
>> >> than 1 geometry properly.
>> >
>> > Would it be possible to add these to the QgsOgrProvider, or are there
>> > some limitations ?
>>
>> Hi Hugo
>>
>> Some technical opinion are available in related PR done by Mark to
>> propose a new Spatialite provider.
>> The general opinion is to check before if it make sense to remove
>> spatialite limitations in the gdal provider to sqlite.
>> There are also opinon that the PR is actually not so simple to review,
>> for the complexity and extension. Oslandia can do it if apport more to
>> his business.
>>
>> IMHO I can't see any problem to merge it after review and have a new
>> or parallel spatialite provicer.
>>
>
> Well, I do: I think that unless there is an overwhelming technical reason to
> take a different route, QGIS should not create alternative providers where
> OGR/GDAL can do the job.

+1.

I strongly believe it would be a dangerous mistake for the QGIS
project to invest further development time and maintenance burden by
extending the spatialite provider, and I've made that view clear on
every discussion related to the spatialite provider over the 3.0
development cycle.

> The reason is both in how open source works: building wonderful applications
> on top of wonderful libraries (GDAL/OGR in this case) and in how we should
> avoid to enlarge the code base without a valid reason.
>
> The right approach in this particular case is IMHO to work with OGR/GDAL to
> add the missing features in the base libraries or to improve the existing
> QGIS providers if the problems is in them, this will prevent duplication and
> lower the maintenance efforts on the shoulders of QGIS developers.

Alessandro has summed up my thoughts exactly.

Nyall