[QGIS-Developer] Drag and drop to PostGIS crash

[Radim Blazek]

On Fri, Jun 2, 2017 at 1:50 AM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> I think copy should definitely be the ONLY behavior here. Otherwise
> there's data loss - user's styling and layer settings will be lost,
> and dragging memory layers will lose all features (admittedly dragging
> memory layers doesn't copy any features anyway, but that makes it
> worse... the contents are irretrievably lost).
>
> I can't work this one out. I think
> QgsDockBrowserTreeView::dragEnterEvent() should be calling
> QTreeView::dragEnterEvent( e ) - without that it's not drawing the
> drop indicators correctly. And in
> QgsDockBrowserTreeView::dragMoveEvent if I reset the drop action to
> CopyAction both before *and* after calling QTreeView::dragMoveEvent( e
> ) then the visual appearance of the drag appears correct, and seems
> ready to perform a copy action... but the actual action performed is
> still a move action.

QTreeView::dragEnterEvent() and QTreeView::dropEvent() override the
action calling acceptProposedAction(). No idea what Trolls intended. I
have forced CopyAction  before and after in both dragMoveEvent AND
dropEvent and it seems to work.

I have implemented DD for memory layers for postgis and spatialite. I
don't have db2, mssql, if maintainers of them are interested, look
into fb6f181. It should be probably all rewritten because there is a
lot of similar code in providers' Qgs...Item::handleDrop(). The
handleDrop() should be implemented in QgsDataCollectionItem and
importLayer() added in items?

Memory layer is identified by pid and layerId which are appended to
uri only for this purpose. Not nice, I could not invent anything
cleaner.

Radim