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

Sun Jul 10 14:48:40 PDT 2022

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 at 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 at lists.osgeo.org> wrote:
>
>> Hi Richard
>>
>> A domingo, 10/07/2022, 08:56, Richard Duivenvoorde via QGIS-Developer <
>> qgis-developer at 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 <project>.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 at 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 at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20220710/081d683a/attachment.htm>