Several times I've noticed that there is a need to use views (as a
'datasource') in addition to tables on an Oracle database. Now, one has to
configure this manually, by making an info.xml file for the view
(identical to one for a table). This isn't very difficult, but the fact
that a user can't use the web admin tool to configure new featureTypes
based on a view, makes users think they can't use views at all.
Anyway, the 'trick' with the manually defined info.xml works fine, but it
isn't possible to define what the primary key is. That is, Geoserver gives
back (random) values for the FeatureId.
Wouldn't it be nice if:
a) a user can use the web admin tool to configure featuretypes from views
b) the FeatureId can be specified (using the web admin tool :)), or be
detected somehow, so that 'neat' FeatureIds are returned?
Maybe b) asks for a thorough revision, but it would be nice to have better
support for views.
Several times I've noticed that there is a need to use views (as a
'datasource') in addition to tables on an Oracle database. Now, one has to
configure this manually, by making an info.xml file for the view
(identical to one for a table). This isn't very difficult, but the fact
that a user can't use the web admin tool to configure new featureTypes
based on a view, makes users think they can't use views at all.
Hi Brentjens:
Interestingly enough it is kind of accidental that views are supported My impression is the Oracle support written on the Geotools side could provide both views and tables as the available FeatureTypes for the Oracle DataStore.
But right now it just lists the table ... so I am CCing the devel list with and idea.
What do people think of listing both Views and Tables from the JDBC DataStores. The views can show up as read only FeaturesSources and the tables can be Read/Write FeatureStores.
So just to add to your list ...
a) a user can use the web admin tool to configure featuretypes from views
b) the FeatureId can be specified (using the web admin tool :)), or be detected somehow, so that 'neat' FeatureIds are returned?
c) Detect views and provide read/only access to them as FeatureSources.
Several times I've noticed that there is a need to use views (as a
'datasource') in addition to tables on an Oracle database. Now, one has to
configure this manually, by making an info.xml file for the view
(identical to one for a table). This isn't very difficult, but the fact
that a user can't use the web admin tool to configure new featureTypes
based on a view, makes users think they can't use views at all.
Anyway, the 'trick' with the manually defined info.xml works fine, but it
isn't possible to define what the primary key is. That is, Geoserver gives
back (random) values for the FeatureId.
Wouldn't it be nice if:
a) a user can use the web admin tool to configure featuretypes from views
b) the FeatureId can be specified (using the web admin tool :)), or be
detected somehow, so that 'neat' FeatureIds are returned?
Maybe b) asks for a thorough revision, but it would be nice to have better
support for views.
This would be nice. And we actually have the hooks for it, since Andrea
made a nice FIDMapper, which could do things just like this. It would be
easier if there was a nice default behaviour we had for views, but then I
don't know what that would be. Making it user configurable is harder,
since we would need to set up a better framework and use the web admin
tool.
As a side note, I am looking to fully support views, and arbitrary
mappings, expanding on the work sco did, for geoserver 1.3. It would
allow you to configure in geoserver directly, instead of having to make
views in your db. Though better support for normal views would be a good
first step.
Chris
What do other people think of this?
Best regards,
Thijs
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-----Original Message-----
From: Chris Holmes <cholmes@anonymised.com>
To: Thijs Brentjens <thijsb@anonymised.com>
Cc: geoserver-devel@lists.sourceforge.net
Date: Tue, 21 Dec 2004 10:12:06 -0500 (EST)
Subject: Re: [Geoserver-devel] Using views in addition to tables (Oracle
and maybe other dbs as well)
> Hi,
>
> Several times I've noticed that there is a need to use views (as a
> 'datasource') in addition to tables on an Oracle database. Now, one
has to
> configure this manually, by making an info.xml file for the view
> (identical to one for a table). This isn't very difficult, but the
fact
> that a user can't use the web admin tool to configure new
featureTypes
> based on a view, makes users think they can't use views at all.
Ok, this should not be too hard. I think all we need to do is add
"VIEW"
as a type to our loadTypeNamesFromDatabase method in http://gtsvn.refractions.net/geotools/trunk/gt/module/main/src/org/geot
ools/data/jdbc/FeatureTypeInfo.java
Could you make a jira in geoserver for me? And if you're feeling nice
make it in geotools too and link the geos one to i?
I'll do that.
> Anyway, the 'trick' with the manually defined info.xml works fine,
but it
> isn't possible to define what the primary key is. That is, Geoserver
gives
> back (random) values for the FeatureId.
>
> Wouldn't it be nice if:
> a) a user can use the web admin tool to configure featuretypes from
views
> b) the FeatureId can be specified (using the web admin tool :)), or
be
> detected somehow, so that 'neat' FeatureIds are returned?
>
> Maybe b) asks for a thorough revision, but it would be nice to have
better
> support for views.
This would be nice. And we actually have the hooks for it, since
Andrea
made a nice FIDMapper, which could do things just like this. It would
be
easier if there was a nice default behaviour we had for views, but then
I
don't know what that would be. Making it user configurable is harder,
since we would need to set up a better framework and use the web admin
tool.
As a side note, I am looking to fully support views, and arbitrary
mappings, expanding on the work sco did, for geoserver 1.3. It would
allow you to configure in geoserver directly, instead of having to make
views in your db. Though better support for normal views would be a
good
first step.
This would be great as well, but I think it would be best to have both:
supporting views (that already might exist, so why redefine them in the
geoserver web admin tool, this would please the DBA's most I think )
and have the possibility to configure it in Geoserver directly as well
(which is very convenient for application development).
Oh, and from Jody's reply (and the one I just read from Chris): listing
them in the web admin tool as read-only (and maybe 'updatable' or
whatever) would be quite nice!
Thijs
Chris
>
> What do other people think of this?
>
> Best regards,
> Thijs
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> As a side note, I am looking to fully support views, and arbitrary
> mappings, expanding on the work sco did, for geoserver 1.3. It would
> allow you to configure in geoserver directly, instead of having to make
> views in your db. Though better support for normal views would be a
> good
> first step.
>
This would be great as well, but I think it would be best to have both:
supporting views (that already might exist, so why redefine them in the
geoserver web admin tool, this would please the DBA's most I think )
and have the possibility to configure it in Geoserver directly as well
(which is very convenient for application development).
Agreed. Perhaps DBA's would just configure the FID mapping (you can't
define primary keys on a view, can you? If you could then I feel like
things should work in GeoServer), and then be good to go. Thinking on it
further, we _should_ be able to get views to work better in postgis. For
some reason I always thought this would be hard, but I think all we need
to do is require users to add the geometry column to the geometry_columns
table. Should write this up in the docs...
Oh, and from Jody's reply (and the one I just read from Chris): listing
them in the web admin tool as read-only (and maybe 'updatable' or
whatever) would be quite nice!
That shouldn't be too hard - try to bring it up again when we get closer,
or include it in a jira issue. We could just put a little * by the read
only ones or something.
Chris
Thijs
> Chris
>
> >
> > What do other people think of this?
> >
> > Best regards,
> > Thijs
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real
> users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
> --
>
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
My impression is the Oracle support written on the Geotools side could provide both views and tables as the available FeatureTypes for the Oracle DataStore.
)