[Qgis-user] QGis server project files stored in DB?

Thu Aug 13 00:45:26 PDT 2015

Hi,

did you think about using a Python server plugin?

I imagine a simple plugin that on each incoming request queries the DB for
the requested project.

If the project is not in the DB you return an exception (or whatever you
want, you can also dynamically build a page with existing/accessible
projects).

If the project is accessible, the plugin fetches it from the DB to a folder
and serves it using the normal flow (a caching logic here that checks if
the project has changed from the last request would speed things up a bit).

Some basic server Python plugin documentation is now in place:
http://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/server.html

Regards.

2015-08-12 16:58 GMT+02:00 lars lingner <gislars+list at gmail.com>:

> Hi,
>
> thanks for the feedback so far. If feel I have to explain my usecase a
> little bit more. It is basically a  "well designed server setup" (TM)
> which provides map services via QGis Server. The configuration and
> project files are tested and can only be changed by authorized users.
>
> Other users are working with QGis Desktop developing project files.
> These files are deployed on the server and being used there for the map
> services. So there is a barrier which filters out most of faulty project
> files like not accessible host names or user credentials. That is why I
> didn't think about the problems regarding access rights, permissions and
> environment settings.
>
> My simple thought was, if I have a working project file consumed by QGis
> Server, couldn't I use a DB as source of it. There is already a DB sync
> for the data in place. Handling QGis project files now, I'm already
> responsible that all resources mentioned are accessible. I wouldn't
> expect QGis to do this job.
>
> But of course, these questions arise and more are likely to come. I
> wouldn't expect a feature like this being useful for _all_ QGis users,
> OTOH which feature does? :)
>
> One problem I could see is the overhead getting the file out of the DB.
> When a server process is spawned, the project file is processed. I can
> imagine checking if the project has changed and respawning the server
> process if needed would add some amount of overhead.
>
> For now I'm trying to work with a wrapper script. This is selecting the
> right "QGis file row" and writing it in a file which is than consumed by
> QGis server.
>
>
> Thanks for listening :)
>
> Lars
>
>
> On 12.08.2015 16:03, Andrea Peri wrote:
> > So you assume to have grants to write in the table where is stored the
> > published informazioni.
> > This is not always true. The dba amministratore of a published
> environment
> > not like to have some cowboy to write into its DBMS.
> >
> > Instead in low profile environment where there is 1 user only and it is
> > webadmin , qgis user and perhaps also publisher. Not always it ha also
> the
> > capability to admin a DBMS like postgres.
> >
> > I feat that this option increasing complexity will reduce the
> installation
> > of qgis-server.
> >
> > A.
> > Il 12/ago/2015 03:29 PM, "James Keener" <jim at jimkeener.com> ha scritto:
> >
> >> I was also looking for this a bit back and never found a solution. I
> ended
> >> up using other software, unfortunately.
> >>
> >> As for being less flexible, it is exactly as flexible as a qgs file
> would
> >> be, it's just that they could be manipulated and created more easily.  I
> >> would love to see the parts of the file broke out in the database and
> not
> >> just using a single text blob, though.
> >>
> >> Also, setting up identical-enough is fairly trivial, especially if most
> of
> >> the layers are already coming from a database, or known cache of
> shapefiles.
> >>
> >> Jim
> >>
> >> On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri <aperi2007 at gmail.com>
> wrote:
> >>
> >>> I don't guess is more flexible.
> >>> Infact usually the teting environment is never exactly exals to the
> >>> publish environmnet.
> >>>
> >>> A file allw to open and correct the paths from develop and publish
> >>> environment.
> >>> Also the svg symbols could be not exactly with the same path from
> >>> develop and publish environment.
> >>>
> >>> So having a same project in a db is more complex becasue need to have
> >>> two environment exactly the same.
> >>> And this is not possible.
> >>> .
> >>>
> >>> I guess the db storing for project could be more flexible only if the
> >>> paths to the layers and relative paths of svg was not stored in the
> >>> project file but instead in other files.
> >>>
> >>> My 2ct.
> >>>
> >>> A.
> >>>
> >>>
> >>> 2015-08-12 15:06 GMT+02:00 lars lingner <gislars+list at gmail.com>:
> >>>> Hello,
> >>>>
> >>>> I'm looking for a solution for storing QGis project files (qgs) in a
> >>>> PostgreSQL database. Storing the files in a table isn't actually the
> >>>> problem, but getting it out and feeding it to QGis server.
> >>>>
> >>>> Did anyone had this need already? Would this be a good idea?
> >>>>
> >>>> In my use case the project files are generated, based on a default
> >>>> project file. Having the file in the DB would give more flexibility.
> >>>>
> >>>> Since saving the style in DB is already supported by QGis, I'm just
> >>>> curious of opinions of other users or developers.
> >>>>
> >>>> Thanks in advance for any feedback
> >>>>
> >>>> Lars
> >>>> _______________________________________________
> >>>> Qgis-user mailing list
> >>>> Qgis-user at lists.osgeo.org
> >>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> >>>
> >>>
> >>>
> >>> --
> >>> -----------------
> >>> Andrea Peri
> >>> . . . . . . . . .
> >>> qwerty àèìòù
> >>> -----------------
> >>> _______________________________________________
> >>> Qgis-user mailing list
> >>> Qgis-user at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> >>>
> >>
> >>
> >
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>

-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20150813/a1fd3744/attachment.html>