Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer 
I don't think so. I think the python console has its specific function by
now. I think an SQL interface should provide different functions and
integrations, maybe based on GDAL that seems less and less important and
may play a stronger role as Spatialite.
At the same time, I understand that having two consoles may be confusing
for some of us.
Maybe it's just a boomers' approach, I would love even getting a bash
interface, a lua and a node one because they serve different approaches...
;.)

On Thu, Sep 8, 2022 at 11:34 PM Alexandre Neto 
wrote:

> It's probably out of the scope of this migration, but following your idea,
> I wonder if the python console/editor and underlying code could be used
> also to run SQL?
>
> A quinta, 8/09/2022, 22:13, Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> escreveu:
>
>> This decision makes sense to me, but I still miss an SQL interface – I
>> mean an SQL-oriented interface for data as GDAL does even for unnecessary
>> cases. QGIS has a python-first approach but I don't think this should be
>> the only or the mandatory way to approach GIS data.
>>
>> Alexandre Neto says:
>>
>>> I am big QGIS/PostGIS user and DB manager in QGIS allows me to do
>>> something that you can't do elsewhere, run long spatial analysis using SQL.
>>
>> while Richard Duivenvoorde replies:
>>
>>> My de facto client is DBeaver, a cross platform FOSS general Database
>>> client (written in Java).
>>> It even has a simple spatial viewer (as: show geometries on OSM, both
>>> for Postgis and Geopackages) in the data tabs.
>>
>>
>>  DBeaver is a great tool if you have to move data from one DBMS to
>> another and has even a simple geometry viewer, but what I think QGIS should
>> provide is a data-oriented interface, something that could mix procedural
>> tools that work on the client with dbms resident functions. In reality, if
>> you deal with data and resort to views based on native Postgis functions,
>> it's much better to have a good SQL interface in QGIS than simply
>> visualising geometries in DBeaver. Let alone, as Paolo Cavallini says,
>> using topology.
>> Nothing against the idea of a better integration that implies an optional
>> role of the plug-in, but the outcome is an implicit choice for a
>> traditional client-server approach vs a well-balanced orientation we
>> enjoyed. I would appreciate a move in the opposite direction, but it's only
>> a personal preference.
>>
>> On Thu, Sep 8, 2022 at 4:33 PM Alexandre Neto via QGIS-Developer <
>> qgis-developer@lists.osgeo.org> wrote:
>>
>>> Yes, ti seems to. thanks!
>>>
>>> Nyall Dawson  escreveu no dia quinta, 8/09/2022
>>> à(s) 10:16:
>>>
 On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
  wrote:
 >
 > Hi,
 >
 > In the end, Richard ended up closing the project. But I was able to
 create a new one. Can someone with QGIS organization owner privileges
 please make it public?

 Done, I think ...

 Nyall

 >
 > https://github.com/orgs/qgis/projects/3/settings
 >
 > Thanks
 >
 > Alexandre Neto
 >
 >
 > Richard Duivenvoorde via QGIS-Developer <
 qgis-developer@lists.osgeo.org> escreveu no dia quarta, 7/09/2022 à(s)
 16:02:
 >>
 >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
 >> > Hi
 >> >
 >> > Can anyone please create a github project for dbmanager migration?
 I don't have enough permissions for it.
 >>
 >> I had never heard of 'projects'... but Alexandre helpt me to create:
 >>
 >> https://github.com/orgs/qgis/projects/1
 >>
 >> Please let me know if it works...
 >>
 >> Regards,
 >>
 >> Richard Duivenvoorde
 >>
 >> ___
 >> QGIS-Developer mailing list
 >> QGIS-Developer@lists.osgeo.org
 >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
 >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
 >
 > ___
 > QGIS-Developer mailing list
 > QGIS-Developer@lists.osgeo.org
 > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
 > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Alexandre Neto via QGIS-Developer 
It's probably out of the scope of this migration, but following your idea,
I wonder if the python console/editor and underlying code could be used
also to run SQL?

A quinta, 8/09/2022, 22:13, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> escreveu:

> This decision makes sense to me, but I still miss an SQL interface – I
> mean an SQL-oriented interface for data as GDAL does even for unnecessary
> cases. QGIS has a python-first approach but I don't think this should be
> the only or the mandatory way to approach GIS data.
>
> Alexandre Neto says:
>
>> I am big QGIS/PostGIS user and DB manager in QGIS allows me to do
>> something that you can't do elsewhere, run long spatial analysis using SQL.
>
> while Richard Duivenvoorde replies:
>
>> My de facto client is DBeaver, a cross platform FOSS general Database
>> client (written in Java).
>> It even has a simple spatial viewer (as: show geometries on OSM, both for
>> Postgis and Geopackages) in the data tabs.
>
>
>  DBeaver is a great tool if you have to move data from one DBMS to another
> and has even a simple geometry viewer, but what I think QGIS should provide
> is a data-oriented interface, something that could mix procedural tools
> that work on the client with dbms resident functions. In reality, if you
> deal with data and resort to views based on native Postgis functions, it's
> much better to have a good SQL interface in QGIS than simply visualising
> geometries in DBeaver. Let alone, as Paolo Cavallini says, using topology.
> Nothing against the idea of a better integration that implies an optional
> role of the plug-in, but the outcome is an implicit choice for a
> traditional client-server approach vs a well-balanced orientation we
> enjoyed. I would appreciate a move in the opposite direction, but it's only
> a personal preference.
>
> On Thu, Sep 8, 2022 at 4:33 PM Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Yes, ti seems to. thanks!
>>
>> Nyall Dawson  escreveu no dia quinta, 8/09/2022
>> à(s) 10:16:
>>
>>> On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
>>>  wrote:
>>> >
>>> > Hi,
>>> >
>>> > In the end, Richard ended up closing the project. But I was able to
>>> create a new one. Can someone with QGIS organization owner privileges
>>> please make it public?
>>>
>>> Done, I think ...
>>>
>>> Nyall
>>>
>>> >
>>> > https://github.com/orgs/qgis/projects/3/settings
>>> >
>>> > Thanks
>>> >
>>> > Alexandre Neto
>>> >
>>> >
>>> > Richard Duivenvoorde via QGIS-Developer <
>>> qgis-developer@lists.osgeo.org> escreveu no dia quarta, 7/09/2022 à(s)
>>> 16:02:
>>> >>
>>> >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
>>> >> > Hi
>>> >> >
>>> >> > Can anyone please create a github project for dbmanager migration?
>>> I don't have enough permissions for it.
>>> >>
>>> >> I had never heard of 'projects'... but Alexandre helpt me to create:
>>> >>
>>> >> https://github.com/orgs/qgis/projects/1
>>> >>
>>> >> Please let me know if it works...
>>> >>
>>> >> Regards,
>>> >>
>>> >> Richard Duivenvoorde
>>> >>
>>> >> ___
>>> >> QGIS-Developer mailing list
>>> >> QGIS-Developer@lists.osgeo.org
>>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> >
>>> > ___
>>> > QGIS-Developer mailing list
>>> > QGIS-Developer@lists.osgeo.org
>>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer 
This decision makes sense to me, but I still miss an SQL interface – I mean
an SQL-oriented interface for data as GDAL does even for unnecessary cases.
QGIS has a python-first approach but I don't think this should be the only
or the mandatory way to approach GIS data.

Alexandre Neto says:

> I am big QGIS/PostGIS user and DB manager in QGIS allows me to do
> something that you can't do elsewhere, run long spatial analysis using SQL.

while Richard Duivenvoorde replies:

> My de facto client is DBeaver, a cross platform FOSS general Database
> client (written in Java).
> It even has a simple spatial viewer (as: show geometries on OSM, both for
> Postgis and Geopackages) in the data tabs.


 DBeaver is a great tool if you have to move data from one DBMS to another
and has even a simple geometry viewer, but what I think QGIS should provide
is a data-oriented interface, something that could mix procedural tools
that work on the client with dbms resident functions. In reality, if you
deal with data and resort to views based on native Postgis functions, it's
much better to have a good SQL interface in QGIS than simply visualising
geometries in DBeaver. Let alone, as Paolo Cavallini says, using topology.
Nothing against the idea of a better integration that implies an optional
role of the plug-in, but the outcome is an implicit choice for a
traditional client-server approach vs a well-balanced orientation we
enjoyed. I would appreciate a move in the opposite direction, but it's only
a personal preference.

On Thu, Sep 8, 2022 at 4:33 PM Alexandre Neto via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Yes, ti seems to. thanks!
>
> Nyall Dawson  escreveu no dia quinta, 8/09/2022
> à(s) 10:16:
>
>> On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
>>  wrote:
>> >
>> > Hi,
>> >
>> > In the end, Richard ended up closing the project. But I was able to
>> create a new one. Can someone with QGIS organization owner privileges
>> please make it public?
>>
>> Done, I think ...
>>
>> Nyall
>>
>> >
>> > https://github.com/orgs/qgis/projects/3/settings
>> >
>> > Thanks
>> >
>> > Alexandre Neto
>> >
>> >
>> > Richard Duivenvoorde via QGIS-Developer 
>> escreveu no dia quarta, 7/09/2022 à(s) 16:02:
>> >>
>> >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
>> >> > Hi
>> >> >
>> >> > Can anyone please create a github project for dbmanager migration? I
>> don't have enough permissions for it.
>> >>
>> >> I had never heard of 'projects'... but Alexandre helpt me to create:
>> >>
>> >> https://github.com/orgs/qgis/projects/1
>> >>
>> >> Please let me know if it works...
>> >>
>> >> Regards,
>> >>
>> >> Richard Duivenvoorde
>> >>
>> >> ___
>> >> QGIS-Developer mailing list
>> >> QGIS-Developer@lists.osgeo.org
>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> > ___
>> > QGIS-Developer mailing list
>> > QGIS-Developer@lists.osgeo.org
>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Alexandre Neto via QGIS-Developer 
Yes, ti seems to. thanks!

Nyall Dawson  escreveu no dia quinta, 8/09/2022
à(s) 10:16:

> On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
>  wrote:
> >
> > Hi,
> >
> > In the end, Richard ended up closing the project. But I was able to
> create a new one. Can someone with QGIS organization owner privileges
> please make it public?
>
> Done, I think ...
>
> Nyall
>
> >
> > https://github.com/orgs/qgis/projects/3/settings
> >
> > Thanks
> >
> > Alexandre Neto
> >
> >
> > Richard Duivenvoorde via QGIS-Developer 
> escreveu no dia quarta, 7/09/2022 à(s) 16:02:
> >>
> >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
> >> > Hi
> >> >
> >> > Can anyone please create a github project for dbmanager migration? I
> don't have enough permissions for it.
> >>
> >> I had never heard of 'projects'... but Alexandre helpt me to create:
> >>
> >> https://github.com/orgs/qgis/projects/1
> >>
> >> Please let me know if it works...
> >>
> >> Regards,
> >>
> >> Richard Duivenvoorde
> >>
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Nyall Dawson via QGIS-Developer 
On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
 wrote:
>
> Hi,
>
> In the end, Richard ended up closing the project. But I was able to create a 
> new one. Can someone with QGIS organization owner privileges please make it 
> public?

Done, I think ...

Nyall

>
> https://github.com/orgs/qgis/projects/3/settings
>
> Thanks
>
> Alexandre Neto
>
>
> Richard Duivenvoorde via QGIS-Developer  
> escreveu no dia quarta, 7/09/2022 à(s) 16:02:
>>
>> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
>> > Hi
>> >
>> > Can anyone please create a github project for dbmanager migration? I don't 
>> > have enough permissions for it.
>>
>> I had never heard of 'projects'... but Alexandre helpt me to create:
>>
>> https://github.com/orgs/qgis/projects/1
>>
>> Please let me know if it works...
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Alexandre Neto via QGIS-Developer 
Hi,

In the end, Richard ended up closing the project. But I was able to create
a new one. Can someone with QGIS organization owner privileges please make
it public?

https://github.com/orgs/qgis/projects/3/settings

Thanks

Alexandre Neto


Richard Duivenvoorde via QGIS-Developer 
escreveu no dia quarta, 7/09/2022 à(s) 16:02:

> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
> > Hi
> >
> > Can anyone please create a github project for dbmanager migration? I
> don't have enough permissions for it.
>
> I had never heard of 'projects'... but Alexandre helpt me to create:
>
> https://github.com/orgs/qgis/projects/1
>
> Please let me know if it works...
>
> Regards,
>
> Richard Duivenvoorde
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-08 Thread Alexandre Neto via QGIS-Developer 
Sandro, thanks for the clarification.

Sandro Santilli via QGIS-Developer 
escreveu no dia quarta, 7/09/2022 à(s) 22:28:

> On Tue, Sep 06, 2022 at 06:15:46PM +0200, Paolo Cavallini via
> QGIS-Developer wrote:
> > I believe it is the only way to visualize topogeoms from
>
> Just a clarification: the DBManager TopoViewer does not visualize
> "TopoGeometry" objects (which is what I usually refer to by
> "topogeoms") but simple features being the primitives of topologies.
>
> Visualizing TopoGeometry objects (topology layers) is supported by core
> QGIS (PostgreSQL provider) since version 2.0.0 (2012)
>
> --strk;
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-07 Thread Sandro Santilli via QGIS-Developer 
On Tue, Sep 06, 2022 at 06:15:46PM +0200, Paolo Cavallini via QGIS-Developer 
wrote:
> I believe it is the only way to visualize topogeoms from

Just a clarification: the DBManager TopoViewer does not visualize
"TopoGeometry" objects (which is what I usually refer to by
"topogeoms") but simple features being the primitives of topologies.

Visualizing TopoGeometry objects (topology layers) is supported by core
QGIS (PostgreSQL provider) since version 2.0.0 (2012)

--strk;
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-07 Thread Sandro Santilli via QGIS-Developer 
On Tue, Sep 06, 2022 at 05:41:34PM +0200, Julien Cabieces via QGIS-Developer 
wrote:

> I added recently one comment in your table regarding TopoViewer because I met
> somebody at Foss4G who was using it. From what I understand, it
> generates several vector layers to visualise topology when extension is
> enabled in PostgreSQL.

I used it everytime I'm dealing with topologies, which is daily, on
work days.

> I don't know if it is widely used, if the feature is stable/maintained
> or if there is other QGIS plugin able to provide such visalization.

It's stable and it's maintained (by me). No other QGIS plugins that I
know of do this. It would be nice to get the code ported to the
browser so to show a tree node containing all the topologies defined in
a database and load that layer tree upon double-clicking on them.

--strk;
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-07 Thread Richard Duivenvoorde via QGIS-Developer 

On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:

Hi

Can anyone please create a github project for dbmanager migration? I don't have 
enough permissions for it.


I had never heard of 'projects'... but Alexandre helpt me to create:

https://github.com/orgs/qgis/projects/1

Please let me know if it works...

Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-07 Thread Alexandre Neto via QGIS-Developer 
Hi

Can anyone please create a github project for dbmanager migration? I don't
have enough permissions for it.

Alexandre Neto

Paolo Cavallini via QGIS-Developer 
escreveu no dia terça, 6/09/2022 à(s) 17:16:

> Hi all,
>
> Il 06/09/22 17:41, Julien Cabieces via QGIS-Developer ha scritto:
> >
> > Hi!
> >
> > I added recently one comment in your table regarding TopoViewer because
> I met
> > somebody at Foss4G who was using it. From what I understand, it
> > generates several vector layers to visualise topology when extension is
> > enabled in PostgreSQL.
> >
> > I don't know if it is widely used, if the feature is stable/maintained
>
> I confirm
>
> > or if there is other QGIS plugin able to provide such visalization.
>
> IMNSHO not. I believe it is the only way to visualize topogeoms from
> PostGIS.
>
> Thanks!
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-06 Thread Paolo Cavallini via QGIS-Developer 

Hi all,

Il 06/09/22 17:41, Julien Cabieces via QGIS-Developer ha scritto:


Hi!

I added recently one comment in your table regarding TopoViewer because I met
somebody at Foss4G who was using it. From what I understand, it
generates several vector layers to visualise topology when extension is
enabled in PostgreSQL.

I don't know if it is widely used, if the feature is stable/maintained


I confirm


or if there is other QGIS plugin able to provide such visalization.


IMNSHO not. I believe it is the only way to visualize topogeoms from 
PostGIS.


Thanks!
--
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-06 Thread Julien Cabieces via QGIS-Developer 

Hi!

I added recently one comment in your table regarding TopoViewer because I met
somebody at Foss4G who was using it. From what I understand, it
generates several vector layers to visualise topology when extension is
enabled in PostgreSQL.

I don't know if it is widely used, if the feature is stable/maintained
or if there is other QGIS plugin able to provide such visalization.

Regards,
Julien


> Hi!
>
> I didn't receive much input in this table, so I will go ahead and create a
> few feature requests as Nyall asked for those functionalities not yet
> covered by a viable workaround.
> I will be up to the project to decide which are crucial, nice to have or
> simply won't fix/implement.
>
> Alexandre Neto
>
> Alexandre Neto  escreveu no dia segunda, 8/08/2022
> à(s) 11:52:
>
>> The link...
>>
>>
>>
>> https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing
>>
>> Alexandre Neto
>>
>> A sábado, 6/08/2022, 21:08, Alexandre Neto 
>> escreveu:
>>
>>> Hi,
>>>
>>> Sorry for the long waiting. I have made a functionality matrix for db
>>> manager and possible alternatives. I am not sure if all is correct so
>>> please feel free to edit or comment.
>>>
>>> After your edits I will create the migragion feature requests.
>>>
>>> Best regards,
>>>
>>> Alexandre Neto
>>>
>>> A segunda, 11/07/2022, 08:11, Alexandre Neto 
>>> escreveu:
>>>
 Hi Nyall,

 A segunda, 11/07/2022, 00:47, Nyall Dawson 
 escreveu:

>
> I wonder if you'd be willing to lead an effort to document the missing
> functionality from dbmanager, and file QGIS tickets for these and
> assign them to a new project in the QGIS github for "deprecating db
> manager"?


 Sure I will! I am on vacations, but next week I will start working on it.

 Thanks!

 Alexandre

>>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-09-06 Thread Alexandre Neto via QGIS-Developer 
Hi!

I didn't receive much input in this table, so I will go ahead and create a
few feature requests as Nyall asked for those functionalities not yet
covered by a viable workaround.
I will be up to the project to decide which are crucial, nice to have or
simply won't fix/implement.

Alexandre Neto

Alexandre Neto  escreveu no dia segunda, 8/08/2022
à(s) 11:52:

> The link...
>
>
>
> https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing
>
> Alexandre Neto
>
> A sábado, 6/08/2022, 21:08, Alexandre Neto 
> escreveu:
>
>> Hi,
>>
>> Sorry for the long waiting. I have made a functionality matrix for db
>> manager and possible alternatives. I am not sure if all is correct so
>> please feel free to edit or comment.
>>
>> After your edits I will create the migragion feature requests.
>>
>> Best regards,
>>
>> Alexandre Neto
>>
>> A segunda, 11/07/2022, 08:11, Alexandre Neto 
>> escreveu:
>>
>>> Hi Nyall,
>>>
>>> A segunda, 11/07/2022, 00:47, Nyall Dawson 
>>> escreveu:
>>>

 I wonder if you'd be willing to lead an effort to document the missing
 functionality from dbmanager, and file QGIS tickets for these and
 assign them to a new project in the QGIS github for "deprecating db
 manager"?
>>>
>>>
>>> Sure I will! I am on vacations, but next week I will start working on it.
>>>
>>> Thanks!
>>>
>>> Alexandre
>>>
>>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-08-09 Thread SIGéal via QGIS-Developer 

Great job !
It gave me the opportunity to discover some nice new functionalities 
added since QGIS 3.16.


Thanks,

--
Christophe Damour

Le 08/08/2022 à 12:52, Alexandre Neto via QGIS-Developer a écrit :

The link...


https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing

Alexandre Neto

A sábado, 6/08/2022, 21:08, Alexandre Neto  
escreveu:


Hi,

Sorry for the long waiting. I have made a functionality matrix for
db manager and possible alternatives. I am not sure if all is
correct so please feel free to edit or comment.

After your edits I will create the migragion feature requests.

Best regards,

Alexandre Neto

A segunda, 11/07/2022, 08:11, Alexandre Neto
 escreveu:

Hi Nyall,

A segunda, 11/07/2022, 00:47, Nyall Dawson
 escreveu:


I wonder if you'd be willing to lead an effort to document
the missing
functionality from dbmanager, and file QGIS tickets for
these and
assign them to a new project in the QGIS github for
"deprecating db
manager"? 



Sure I will! I am on vacations, but next week I will start
working on it.

Thanks!

Alexandre


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-08-08 Thread Alexandre Neto via QGIS-Developer 
The link...


https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing

Alexandre Neto

A sábado, 6/08/2022, 21:08, Alexandre Neto  escreveu:

> Hi,
>
> Sorry for the long waiting. I have made a functionality matrix for db
> manager and possible alternatives. I am not sure if all is correct so
> please feel free to edit or comment.
>
> After your edits I will create the migragion feature requests.
>
> Best regards,
>
> Alexandre Neto
>
> A segunda, 11/07/2022, 08:11, Alexandre Neto 
> escreveu:
>
>> Hi Nyall,
>>
>> A segunda, 11/07/2022, 00:47, Nyall Dawson 
>> escreveu:
>>
>>>
>>> I wonder if you'd be willing to lead an effort to document the missing
>>> functionality from dbmanager, and file QGIS tickets for these and
>>> assign them to a new project in the QGIS github for "deprecating db
>>> manager"?
>>
>>
>> Sure I will! I am on vacations, but next week I will start working on it.
>>
>> Thanks!
>>
>> Alexandre
>>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-08-06 Thread Alexandre Neto via QGIS-Developer 
Hi,

Sorry for the long waiting. I have made a functionality matrix for db
manager and possible alternatives. I am not sure if all is correct so
please feel free to edit or comment.

After your edits I will create the migragion feature requests.

Best regards,

Alexandre Neto

A segunda, 11/07/2022, 08:11, Alexandre Neto 
escreveu:

> Hi Nyall,
>
> A segunda, 11/07/2022, 00:47, Nyall Dawson 
> escreveu:
>
>>
>> I wonder if you'd be willing to lead an effort to document the missing
>> functionality from dbmanager, and file QGIS tickets for these and
>> assign them to a new project in the QGIS github for "deprecating db
>> manager"?
>
>
> Sure I will! I am on vacations, but next week I will start working on it.
>
> Thanks!
>
> Alexandre
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-11 Thread Alexandre Neto via QGIS-Developer 
Hi Nyall,

A segunda, 11/07/2022, 00:47, Nyall Dawson 
escreveu:

>
> I wonder if you'd be willing to lead an effort to document the missing
> functionality from dbmanager, and file QGIS tickets for these and
> assign them to a new project in the QGIS github for "deprecating db
> manager"?


Sure I will! I am on vacations, but next week I will start working on it.

Thanks!

Alexandre
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread Nyall Dawson via QGIS-Developer 
On Sun, 10 Jul 2022 at 11:02, Alexandre Neto  wrote:
>
> Hello all,
>
> -1 for me

* snip *

This is all great feedback, thanks!

I wonder if you'd be willing to lead an effort to document the missing
functionality from dbmanager, and file QGIS tickets for these and
assign them to a new project in the QGIS github for "deprecating db
manager"? Some of these shortcomings should be relatively easy to
address (the modal dialog for instance is a relatively straightforward
change).

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer 
I think José has a good suggestion, maybe a fully integrated SQL console
could be the other way around the browser panel.
Having a "Database" Menu without any database management tool could be
funny and deceiving for new users. The idea of having SQL as another
language to manage geographic DBMSs (and not only PostGIS) seems
interesting albeit not new (who remembers MapBasic in MapInfo?). For some
time it seemed that the integration with Spatialite could become so strong
that I was becoming the way to handle all the features of QGIS in a
data-centric way.
Then the affirmation of geopackage seems to have changed the outlook for
QGIS.
c

On Sun, Jul 10, 2022 at 3:06 PM José de Paula Rodrigues via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi, all,
>
> I must say I agree with Alexandre; one of the most precious feature of
> QGIS for me and the folks that work with me is the ability to very quickly
> and easily interact with PostGIS, making experiments, testing a query,
> adjusting, tailoring, comparing with other kinds of data sets, right there
> on the QGIS interface. I also agree that QGIS is not a database
> "manager"/"workshop"/"weaver" tool, so tasks such as creating database
> models, adding or removing columns, creating or droping
> tables/schemas/databases/roles might be out of scope for QGIS.
>
> If the leaders really think the DB Manager plugin should go away, perhaps
> the current functionality of the SQL Window from DB Manager (with the
> ability to create a layer right from the query) could be moved to something
> akin to the current Python console.
>
> One of the greatest strengths of QGIS, compared to the proprietary
> industry leader, is the ease and immediacy of working with all kinds of
> different dataset types, and I feel that if the DB manager goes away
> without some sort of replacement for its query window, this QGIS advantage
> will shrink a little.
>
> Thank you all.
>
> On Sun, Jul 10, 2022 at 8:51 AM Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi Richard
>>
>> A domingo, 10/07/2022, 08:56, Richard Duivenvoorde via QGIS-Developer <
>> qgis-developer@lists.osgeo.org> escreveu:
>>
>>> On 7/10/22 03:02, Alexandre Neto via QGIS-Developer wrote:
>>>
>>> > This db manager functionality is unique, and is (in my opinion) one of
>>> the reasons why QGIS is PostGIS de facto client.
>>>
>>> Hi Alexandre,
>>>
>>> My de facto client is DBeaver, a cross platform FOSS general Database
>>> client (written in Java).
>>>
>>
>> I know dbeaver and like it alot and I use it too, but IMHO sending people
>> to another software is not a solution.
>>
>> It even has a simple spatial viewer (as: show geometries on OSM, both for
>>> Postgis and Geopackages) in the data tabs.
>>> (in my setup I have Mysql(spatial), Postgis, Geopackages and Oracle
>>> connections in one set)
>>>
>>> Changing constraints/permissions/edits in data etc etc is really
>>> 'simple' (as in via gui).
>>>
>>
>> This is what I use dbeaver for, and as I said before that is not my main
>> concern.
>>
>>
>>> So running a spatial analysis to me is:
>>> - run a query in a .sql file, create a view or temporary table
>>> for it
>>> - load it in QGIS
>>> (- saving all queries including comments in that sql file)
>>>
>>
>> Now this is where I think the workflow is incomparable. In QGIS you can
>> overlap and see several results at the same time. something that it's not
>> possible to do in dbeaver (or pgadmin). You can easily change your query
>> and reload again in a very easy and fast way. Creating views or temporary
>> tables in dbeaver to go and open it in QGIS, then if something went off go
>> back to dveaver do it again... Nah... :-p
>>
>>
>>> Would that be a work around for you?
>>>
>>> It is like: A DB client like DBeaver should not try to be a (Q)GIS
>>> and vice versa ;-)
>>>
>>
>> I agree! My worries are not power users like you and me, we can use
>> several software at the same time without crossing the wires, But it's damn
>> hard to make common GIS folks transition to spatial databases and spatial
>> SQL. Although Alessandro brilliant work will help this transition, the SQL
>> editor from dbmanager was by far the best tool for spatial SQL.
>>
>> This being said, I understand that db manager will eventually die anyway
>> for lack of maintenance if nothing is done otherwise. I just ask for some
>> time so we have a plan for making sure that important functionality is not
>> delegated to third party plugins.
>>
>> Maybe I should lead a QEP followed by a crowd funding? If that is the
>> issue.
>>
>> "We" added lots of new functionality to QGIS, some of which I probably
>> won't ever use, I am ok with it, but it's hard to see functionality I use
>> everyday go away.
>>
>> Thanks,
>>
>> Alexandre
>>
>>
>>> Regards,
>>>
>>> Richard Duivenvoorde
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info:

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread José de Paula Rodrigues via QGIS-Developer 
Hi, all,

I must say I agree with Alexandre; one of the most precious feature of QGIS
for me and the folks that work with me is the ability to very quickly and
easily interact with PostGIS, making experiments, testing a query,
adjusting, tailoring, comparing with other kinds of data sets, right there
on the QGIS interface. I also agree that QGIS is not a database
"manager"/"workshop"/"weaver" tool, so tasks such as creating database
models, adding or removing columns, creating or droping
tables/schemas/databases/roles might be out of scope for QGIS.

If the leaders really think the DB Manager plugin should go away, perhaps
the current functionality of the SQL Window from DB Manager (with the
ability to create a layer right from the query) could be moved to something
akin to the current Python console.

One of the greatest strengths of QGIS, compared to the proprietary industry
leader, is the ease and immediacy of working with all kinds of different
dataset types, and I feel that if the DB manager goes away without some
sort of replacement for its query window, this QGIS advantage will shrink a
little.

Thank you all.

On Sun, Jul 10, 2022 at 8:51 AM Alexandre Neto via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi Richard
>
> A domingo, 10/07/2022, 08:56, Richard Duivenvoorde via QGIS-Developer <
> qgis-developer@lists.osgeo.org> escreveu:
>
>> On 7/10/22 03:02, Alexandre Neto via QGIS-Developer wrote:
>>
>> > This db manager functionality is unique, and is (in my opinion) one of
>> the reasons why QGIS is PostGIS de facto client.
>>
>> Hi Alexandre,
>>
>> My de facto client is DBeaver, a cross platform FOSS general Database
>> client (written in Java).
>>
>
> I know dbeaver and like it alot and I use it too, but IMHO sending people
> to another software is not a solution.
>
> It even has a simple spatial viewer (as: show geometries on OSM, both for
>> Postgis and Geopackages) in the data tabs.
>> (in my setup I have Mysql(spatial), Postgis, Geopackages and Oracle
>> connections in one set)
>>
>> Changing constraints/permissions/edits in data etc etc is really 'simple'
>> (as in via gui).
>>
>
> This is what I use dbeaver for, and as I said before that is not my main
> concern.
>
>
>> So running a spatial analysis to me is:
>> - run a query in a .sql file, create a view or temporary table
>> for it
>> - load it in QGIS
>> (- saving all queries including comments in that sql file)
>>
>
> Now this is where I think the workflow is incomparable. In QGIS you can
> overlap and see several results at the same time. something that it's not
> possible to do in dbeaver (or pgadmin). You can easily change your query
> and reload again in a very easy and fast way. Creating views or temporary
> tables in dbeaver to go and open it in QGIS, then if something went off go
> back to dveaver do it again... Nah... :-p
>
>
>> Would that be a work around for you?
>>
>> It is like: A DB client like DBeaver should not try to be a (Q)GIS
>> and vice versa ;-)
>>
>
> I agree! My worries are not power users like you and me, we can use
> several software at the same time without crossing the wires, But it's damn
> hard to make common GIS folks transition to spatial databases and spatial
> SQL. Although Alessandro brilliant work will help this transition, the SQL
> editor from dbmanager was by far the best tool for spatial SQL.
>
> This being said, I understand that db manager will eventually die anyway
> for lack of maintenance if nothing is done otherwise. I just ask for some
> time so we have a plan for making sure that important functionality is not
> delegated to third party plugins.
>
> Maybe I should lead a QEP followed by a crowd funding? If that is the
> issue.
>
> "We" added lots of new functionality to QGIS, some of which I probably
> won't ever use, I am ok with it, but it's hard to see functionality I use
> everyday go away.
>
> Thanks,
>
> Alexandre
>
>
>> Regards,
>>
>> Richard Duivenvoorde
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
... et cognoscetis veritatem et veritas liberabit vos.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread Alexandre Neto via QGIS-Developer 
Hi Richard

A domingo, 10/07/2022, 08:56, Richard Duivenvoorde via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> On 7/10/22 03:02, Alexandre Neto via QGIS-Developer wrote:
>
> > This db manager functionality is unique, and is (in my opinion) one of
> the reasons why QGIS is PostGIS de facto client.
>
> Hi Alexandre,
>
> My de facto client is DBeaver, a cross platform FOSS general Database
> client (written in Java).
>

I know dbeaver and like it alot and I use it too, but IMHO sending people
to another software is not a solution.

It even has a simple spatial viewer (as: show geometries on OSM, both for
> Postgis and Geopackages) in the data tabs.
> (in my setup I have Mysql(spatial), Postgis, Geopackages and Oracle
> connections in one set)
>
> Changing constraints/permissions/edits in data etc etc is really 'simple'
> (as in via gui).
>

This is what I use dbeaver for, and as I said before that is not my main
concern.


> So running a spatial analysis to me is:
> - run a query in a .sql file, create a view or temporary table
> for it
> - load it in QGIS
> (- saving all queries including comments in that sql file)
>

Now this is where I think the workflow is incomparable. In QGIS you can
overlap and see several results at the same time. something that it's not
possible to do in dbeaver (or pgadmin). You can easily change your query
and reload again in a very easy and fast way. Creating views or temporary
tables in dbeaver to go and open it in QGIS, then if something went off go
back to dveaver do it again... Nah... :-p


> Would that be a work around for you?
>
> It is like: A DB client like DBeaver should not try to be a (Q)GIS and
> vice versa ;-)
>

I agree! My worries are not power users like you and me, we can use several
software at the same time without crossing the wires, But it's damn hard to
make common GIS folks transition to spatial databases and spatial SQL.
Although Alessandro brilliant work will help this transition, the SQL
editor from dbmanager was by far the best tool for spatial SQL.

This being said, I understand that db manager will eventually die anyway
for lack of maintenance if nothing is done otherwise. I just ask for some
time so we have a plan for making sure that important functionality is not
delegated to third party plugins.

Maybe I should lead a QEP followed by a crowd funding? If that is the issue.

"We" added lots of new functionality to QGIS, some of which I probably
won't ever use, I am ok with it, but it's hard to see functionality I use
everyday go away.

Thanks,

Alexandre


> Regards,
>
> Richard Duivenvoorde
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread Richard Duivenvoorde via QGIS-Developer 

On 7/10/22 03:02, Alexandre Neto via QGIS-Developer wrote:


This db manager functionality is unique, and is (in my opinion) one of the 
reasons why QGIS is PostGIS de facto client.


Hi Alexandre,

My de facto client is DBeaver, a cross platform FOSS general Database client 
(written in Java).
It even has a simple spatial viewer (as: show geometries on OSM, both for 
Postgis and Geopackages) in the data tabs.
(in my setup I have Mysql(spatial), Postgis, Geopackages and Oracle connections 
in one set)

Changing constraints/permissions/edits in data etc etc is really 'simple' (as 
in via gui).

So running a spatial analysis to me is:
- run a query in a .sql file, create a view or temporary table for it
- load it in QGIS
(- saving all queries including comments in that sql file)

Would that be a work around for you?

It is like: A DB client like DBeaver should not try to be a (Q)GIS and vice 
versa ;-)

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-10 Thread SIGéal via QGIS-Developer 

Hello,

I fully support that -1

I submitted a feature request some weeks ago to suggest that Explorer 
SQL functionalities should work on a non modal way :

https://github.com/qgis/QGIS/issues/49091

--
Christophe Damour

Le 10/07/2022 à 03:02, Alexandre Neto via QGIS-Developer a écrit :

Hello all,

-1 for me

I am big QGIS/PostGIS user and DB manager in QGIS allows me to do 
something that you can't do elsewhere, run long spatial analysis using 
SQL.


I understand the development reasons for removing db manager from the 
official release and I really enjoy all the effort that Alessandro put 
to bring most functionality to the browser. Nevertheless, I don't 
think it fully replaces db manager querying functionality, and I 
really don't think it will ever do.


The execute SQL dialog is great and amazingly fast, but it doesn't 
replace the db manager editor. The QGIS SQL Editor (db manager or not) 
needs to be an independent window that one can keep open for as long 
as needed to develop and run queries step by step, see the results, 
load them in the project, re-run etc... Also, it is almost mandatory 
that the user, while having the SQL script open, can check tables 
details, like column names, preview their values, etc... to help write 
the queries. We need an independent window or in the limit a panel to 
allow that together with the browser panel.


This db manager functionality is unique, and is (in my opinion) one of 
the reasons why QGIS is PostGIS de facto client.


There are other minor functionality that is still not present, but can 
be added later, like being able to create and manage constraints. Or 
easily create a view from a query.


I understand that for now the functionality I miss would be available 
as an external plugin, but, not being in core, soon it will just stop 
working, and no one will care. QGIS was born as PostGIS query and 
visualiser client, in my humble opinion, by removing db manager at 
these stage we are downgrading QGIS functionality.


Thanks,

Alexandre Neto





A sexta, 8/07/2022, 18:12, Paolo Cavallini via QGIS-Developer 
 escreveu:


Hi all,
are we going to implement this? Apparently nobody objects.
I'd add to the list the Topology sub plugin by strk. Probably not
widely
used, but an unique feature.
I confirm that in the meantime the table historicization has been
broken, one more reason for not shipping DB Manager in the current
state.
Cheers.

Il 22/06/22 07:55, Nyall Dawson ha scritto:

> - Saving/re-running previously saved SQL queries

very useful to me. also loading the result of a query as a new layer

> - Switching to the simplified "SQL builder" dialog for creating
a SQL query
> - Truncating a table (this is available through a Processing
> algorithm, just not via browser)
> - Attribute index creation (this is available through a Processing
> algorithm, just not via browser)

handy but not crucial

> - !! Support for editing an existing column (changing
name/type). This
> is the biggest functionality gap -- changing existing column
types is
> not available elsewhere in QGIS
> - Listing database triggers

I'd add storicization of a table - I couldn't find anything easier
for this.

Cheers.
-- 
Paolo Cavallini

www.faunalia.eu  - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-09 Thread Alexandre Neto via QGIS-Developer 
Hello all,

-1 for me

I am big QGIS/PostGIS user and DB manager in QGIS allows me to do something
that you can't do elsewhere, run long spatial analysis using SQL.

I understand the development reasons for removing db manager from the
official release and I really enjoy all the effort that Alessandro put to
bring most functionality to the browser. Nevertheless, I don't think it
fully replaces db manager querying functionality, and I really don't think
it will ever do.

The execute SQL dialog is great and amazingly fast, but it doesn't replace
the db manager editor. The QGIS SQL Editor (db manager or not) needs to be
an independent window that one can keep open for as long as needed to
develop and run queries step by step, see the results, load them in the
project, re-run etc... Also, it is almost mandatory that the user, while
having the SQL script open, can check tables details, like column names,
preview their values, etc... to help write the queries. We need an
independent window or in the limit a panel to allow that together with the
browser panel.

This db manager functionality is unique, and is (in my opinion) one of the
reasons why QGIS is PostGIS de facto client.

There are other minor functionality that is still not present, but can be
added later, like being able to create and manage constraints. Or easily
create a view from a query.

I understand that for now the functionality I miss would be available as an
external plugin, but, not being in core, soon it will just stop working,
and no one will care. QGIS was born as PostGIS query and visualiser client,
in my humble opinion, by removing db manager at these stage we are
downgrading QGIS functionality.

Thanks,

Alexandre Neto





A sexta, 8/07/2022, 18:12, Paolo Cavallini via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi all,
> are we going to implement this? Apparently nobody objects.
> I'd add to the list the Topology sub plugin by strk. Probably not widely
> used, but an unique feature.
> I confirm that in the meantime the table historicization has been
> broken, one more reason for not shipping DB Manager in the current state.
> Cheers.
>
> Il 22/06/22 07:55, Nyall Dawson ha scritto:
>
> > - Saving/re-running previously saved SQL queries
>
> very useful to me. also loading the result of a query as a new layer
>
> > - Switching to the simplified "SQL builder" dialog for creating a SQL
> query
> > - Truncating a table (this is available through a Processing
> > algorithm, just not via browser)
> > - Attribute index creation (this is available through a Processing
> > algorithm, just not via browser)
>
> handy but not crucial
>
> > - !! Support for editing an existing column (changing name/type). This
> > is the biggest functionality gap -- changing existing column types is
> > not available elsewhere in QGIS
> > - Listing database triggers
>
> I'd add storicization of a table - I couldn't find anything easier for
> this.
>
> Cheers.
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-07-08 Thread Paolo Cavallini via QGIS-Developer 
Hi all,
are we going to implement this? Apparently nobody objects.
I'd add to the list the Topology sub plugin by strk. Probably not widely
used, but an unique feature.
I confirm that in the meantime the table historicization has been
broken, one more reason for not shipping DB Manager in the current state.
Cheers.

Il 22/06/22 07:55, Nyall Dawson ha scritto:

> - Saving/re-running previously saved SQL queries

very useful to me. also loading the result of a query as a new layer

> - Switching to the simplified "SQL builder" dialog for creating a SQL query
> - Truncating a table (this is available through a Processing
> algorithm, just not via browser)
> - Attribute index creation (this is available through a Processing
> algorithm, just not via browser)

handy but not crucial

> - !! Support for editing an existing column (changing name/type). This
> is the biggest functionality gap -- changing existing column types is
> not available elsewhere in QGIS
> - Listing database triggers

I'd add storicization of a table - I couldn't find anything easier for this.

Cheers.
-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-23 Thread SIGéal via QGIS-Developer 

Hi,

+1 for improving QGIS UI consistency !

I recently posted a feature request about "Update SQL Layer" dialog 
which IMHO should be non modal : https://github.com/qgis/QGIS/issues/49091


Reading this discussion, I tested further browser functionnalities and 
came to the conclusion that "Execute SQL" dialog should also be non modal.


And I also wonder why these dialogs could not be included in the Browser 
non modal window, similarly to what is done in DB Manager.


Just my two cents...

--
Christophe Damour

Le 22/06/2022 à 02:43, Nyall Dawson via QGIS-Developer a écrit :

Hi list,

I wanted to raise the discussion around potentially demoting the DB 
Manager plugin to become an opt-in, not installed by default plugin 
available from the QGIS plugin repository only.


It's likely no surprise to anyone on this list, but there's been a 
multi-year effort (mostly thanks to Alessandro!) to move all the 
important functionality of db manager over to the QGIS browser. This 
was driven by a number of factors:


- It was confusing and messy to expose database management tools 
through two completely separate parts of the QGIS interface
- The DB Manager tools are written in provider-specific ways, and 
don't use generic QGIS database/provider API calls. As a result 
there's a lot of duplicate code there, and db manager doesn't gain the 
benefits of new data provider features. (E.g. only a subset of the 
databases supported by QGIS and the browser management tools are 
available for management in db manager)
- The DB Manager functionality wasn't available for other parts of 
QGIS/plugins/scripts/etc to reuse, whereas the browser functionality 
is all nicely exposed to PyQGIS and is used by other parts of QGIS, 
eg. processing tools.
- The Python code implementing db manager is fragile, and is subject 
to semi-frequent regressions/breakage (through no fault of the authors 
-- it's just the nature of complex python applications which aren't 
soaked in unit tests)


I'd say we've reached a stage where the browser now offers all the 
common functionality also available in db manager, and we can start to 
seriously discuss the future of the plugin.


My personal view is that we should demote the plugin to a 
community-maintained, non-officially supported plugin available only 
through the QGIS plugin repositories, and remove it from the default 
QGIS install.


Thoughts/discussion welcome :)

Nyall





___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-22 Thread Tim Sutton via QGIS-Developer 
+1 from me too…we don’t lose anything really here since all the gaps mentioned 
can still be covered by installing the dev manager from the plug-in repo.

Sent from my iPhone

> On 22 Jun 2022, at 08:33, Paolo Cavallini via QGIS-Developer 
>  wrote:
> 
> Hi Nyall,
> 
> Il 22/06/22 07:55, Nyall Dawson ha scritto:
> 
>> - Saving/re-running previously saved SQL queries
> 
> very useful to me. also loading the result of a query as a new layer
> 
>> - Switching to the simplified "SQL builder" dialog for creating a SQL query
>> - Truncating a table (this is available through a Processing
>> algorithm, just not via browser)
>> - Attribute index creation (this is available through a Processing
>> algorithm, just not via browser)
> 
> handy but not crucial
> 
>> - !! Support for editing an existing column (changing name/type). This
>> is the biggest functionality gap -- changing existing column types is
>> not available elsewhere in QGIS
>> - Listing database triggers
> 
> I'd add storicization of a table - I couldn't find anything easier for this.
> 
> Cheers.
> -- 
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-22 Thread Paolo Cavallini via QGIS-Developer 
Hi Nyall,

Il 22/06/22 07:55, Nyall Dawson ha scritto:

> - Saving/re-running previously saved SQL queries

very useful to me. also loading the result of a query as a new layer

> - Switching to the simplified "SQL builder" dialog for creating a SQL query
> - Truncating a table (this is available through a Processing
> algorithm, just not via browser)
> - Attribute index creation (this is available through a Processing
> algorithm, just not via browser)

handy but not crucial

> - !! Support for editing an existing column (changing name/type). This
> is the biggest functionality gap -- changing existing column types is
> not available elsewhere in QGIS
> - Listing database triggers

I'd add storicization of a table - I couldn't find anything easier for this.

Cheers.
-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-22 Thread Alessandro Pasotti via QGIS-Developer 
On Wed, Jun 22, 2022 at 8:52 AM Nyall Dawson  wrote:
>
> On Wed, 22 Jun 2022 at 16:47, Alessandro Pasotti  wrote:
> >
> > I am +1 (of course).
> >
> > Another notable feature gap is virtual layers.
>
> What's the gap there? Can't that all be done from the "New Virtual
> Layer" dialog?


Not much of a functional gap, more a GUI one, virtual layers are not
listed in the browser: there is no icon for them like there is in
DB-manager.


-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-22 Thread Nyall Dawson via QGIS-Developer 
On Wed, 22 Jun 2022 at 16:47, Alessandro Pasotti  wrote:
>
> I am +1 (of course).
>
> Another notable feature gap is virtual layers.

What's the gap there? Can't that all be done from the "New Virtual
Layer" dialog?

Nyall

>
> Kind regards.
>
> On Wed, Jun 22, 2022 at 2:43 AM Nyall Dawson via QGIS-Developer
>  wrote:
> >
> > Hi list,
> >
> > I wanted to raise the discussion around potentially demoting the DB Manager 
> > plugin to become an opt-in, not installed by default plugin available from 
> > the QGIS plugin repository only.
> >
> > It's likely no surprise to anyone on this list, but there's been a 
> > multi-year effort (mostly thanks to Alessandro!) to move all the important 
> > functionality of db manager over to the QGIS browser. This was driven by a 
> > number of factors:
> >
> > - It was confusing and messy to expose database management tools through 
> > two completely separate parts of the QGIS interface
> > - The DB Manager tools are written in provider-specific ways, and don't use 
> > generic QGIS database/provider API calls. As a result there's a lot of 
> > duplicate code there, and db manager doesn't gain the benefits of new data 
> > provider features. (E.g. only a subset of the databases supported by QGIS 
> > and the browser management tools are available for management in db manager)
> > - The DB Manager functionality wasn't available for other parts of 
> > QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is all 
> > nicely exposed to PyQGIS and is used by other parts of QGIS, eg. processing 
> > tools.
> > - The Python code implementing db manager is fragile, and is subject to 
> > semi-frequent regressions/breakage (through no fault of the authors -- it's 
> > just the nature of complex python applications which aren't soaked in unit 
> > tests)
> >
> > I'd say we've reached a stage where the browser now offers all the common 
> > functionality also available in db manager, and we can start to seriously 
> > discuss the future of the plugin.
> >
> > My personal view is that we should demote the plugin to a 
> > community-maintained, non-officially supported plugin available only 
> > through the QGIS plugin repositories, and remove it from the default QGIS 
> > install.
> >
> > Thoughts/discussion welcome :)
> >
> > Nyall
> >
> >
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-22 Thread Alessandro Pasotti via QGIS-Developer 
I am +1 (of course).

Another notable feature gap is virtual layers.

Kind regards.

On Wed, Jun 22, 2022 at 2:43 AM Nyall Dawson via QGIS-Developer
 wrote:
>
> Hi list,
>
> I wanted to raise the discussion around potentially demoting the DB Manager 
> plugin to become an opt-in, not installed by default plugin available from 
> the QGIS plugin repository only.
>
> It's likely no surprise to anyone on this list, but there's been a multi-year 
> effort (mostly thanks to Alessandro!) to move all the important functionality 
> of db manager over to the QGIS browser. This was driven by a number of 
> factors:
>
> - It was confusing and messy to expose database management tools through two 
> completely separate parts of the QGIS interface
> - The DB Manager tools are written in provider-specific ways, and don't use 
> generic QGIS database/provider API calls. As a result there's a lot of 
> duplicate code there, and db manager doesn't gain the benefits of new data 
> provider features. (E.g. only a subset of the databases supported by QGIS and 
> the browser management tools are available for management in db manager)
> - The DB Manager functionality wasn't available for other parts of 
> QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is all 
> nicely exposed to PyQGIS and is used by other parts of QGIS, eg. processing 
> tools.
> - The Python code implementing db manager is fragile, and is subject to 
> semi-frequent regressions/breakage (through no fault of the authors -- it's 
> just the nature of complex python applications which aren't soaked in unit 
> tests)
>
> I'd say we've reached a stage where the browser now offers all the common 
> functionality also available in db manager, and we can start to seriously 
> discuss the future of the plugin.
>
> My personal view is that we should demote the plugin to a 
> community-maintained, non-officially supported plugin available only through 
> the QGIS plugin repositories, and remove it from the default QGIS install.
>
> Thoughts/discussion welcome :)
>
> Nyall
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-21 Thread Nyall Dawson via QGIS-Developer 
On Wed, 22 Jun 2022 at 15:46, Paolo Cavallini via QGIS-Developer
 wrote:
>
> +1 from me. the current state is really confusing.
> there are a number of functions that are still missing from core, but
> what is really used can be added later, in the meantime the external
> plugin can do the job.

Right -- for completeness, here's my understanding of the
functionality available through db manager which ISN'T yet available
via the browser:

- Saving/re-running previously saved SQL queries
- Switching to the simplified "SQL builder" dialog for creating a SQL query
- Truncating a table (this is available through a Processing
algorithm, just not via browser)
- Attribute index creation (this is available through a Processing
algorithm, just not via browser)
- !! Support for editing an existing column (changing name/type). This
is the biggest functionality gap -- changing existing column types is
not available elsewhere in QGIS
- Listing database triggers

Nyall



> thanks Nyall for raising this.
> cheers.
>
> Il 22/06/22 02:43, Nyall Dawson via QGIS-Developer ha scritto:
> > Hi list,
> >
> > I wanted to raise the discussion around potentially demoting the DB
> > Manager plugin to become an opt-in, not installed by default plugin
> > available from the QGIS plugin repository only.
> >
> > It's likely no surprise to anyone on this list, but there's been a
> > multi-year effort (mostly thanks to Alessandro!) to move all the
> > important functionality of db manager over to the QGIS browser. This was
> > driven by a number of factors:
> >
> > - It was confusing and messy to expose database management tools through
> > two completely separate parts of the QGIS interface
> > - The DB Manager tools are written in provider-specific ways, and don't
> > use generic QGIS database/provider API calls. As a result there's a lot
> > of duplicate code there, and db manager doesn't gain the benefits of new
> > data provider features. (E.g. only a subset of the databases supported
> > by QGIS and the browser management tools are available for management in
> > db manager)
> > - The DB Manager functionality wasn't available for other parts of
> > QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is
> > all nicely exposed to PyQGIS and is used by other parts of QGIS, eg.
> > processing tools.
> > - The Python code implementing db manager is fragile, and is subject to
> > semi-frequent regressions/breakage (through no fault of the authors --
> > it's just the nature of complex python applications which aren't soaked
> > in unit tests)
> >
> > I'd say we've reached a stage where the browser now offers all the
> > common functionality also available in db manager, and we can start to
> > seriously discuss the future of the plugin.
> >
> > My personal view is that we should demote the plugin to a
> > community-maintained, non-officially supported plugin available only
> > through the QGIS plugin repositories, and remove it from the default
> > QGIS install.
> >
> > Thoughts/discussion welcome :)
> >
> > Nyall
> >
> >
> >
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

2022-06-21 Thread Paolo Cavallini via QGIS-Developer 
+1 from me. the current state is really confusing.
there are a number of functions that are still missing from core, but
what is really used can be added later, in the meantime the external
plugin can do the job.
thanks Nyall for raising this.
cheers.

Il 22/06/22 02:43, Nyall Dawson via QGIS-Developer ha scritto:
> Hi list,
> 
> I wanted to raise the discussion around potentially demoting the DB
> Manager plugin to become an opt-in, not installed by default plugin
> available from the QGIS plugin repository only.
> 
> It's likely no surprise to anyone on this list, but there's been a
> multi-year effort (mostly thanks to Alessandro!) to move all the
> important functionality of db manager over to the QGIS browser. This was
> driven by a number of factors:
> 
> - It was confusing and messy to expose database management tools through
> two completely separate parts of the QGIS interface
> - The DB Manager tools are written in provider-specific ways, and don't
> use generic QGIS database/provider API calls. As a result there's a lot
> of duplicate code there, and db manager doesn't gain the benefits of new
> data provider features. (E.g. only a subset of the databases supported
> by QGIS and the browser management tools are available for management in
> db manager)
> - The DB Manager functionality wasn't available for other parts of
> QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is
> all nicely exposed to PyQGIS and is used by other parts of QGIS, eg.
> processing tools.
> - The Python code implementing db manager is fragile, and is subject to
> semi-frequent regressions/breakage (through no fault of the authors --
> it's just the nature of complex python applications which aren't soaked
> in unit tests)
> 
> I'd say we've reached a stage where the browser now offers all the
> common functionality also available in db manager, and we can start to
> seriously discuss the future of the plugin.
> 
> My personal view is that we should demote the plugin to a
> community-maintained, non-officially supported plugin available only
> through the QGIS plugin repositories, and remove it from the default
> QGIS install.
> 
> Thoughts/discussion welcome :)
> 
> Nyall
> 
> 
> 
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer