[Geotools-devel] Re: You have CVS access and other questions

[Jody G. <jga...@re...>]

Gabriel Rold=E1n wrote:

>ok. thanks a lot
> =20
>
Cool :-)

>gabriel.
>
>P.S.: Jody, I have an issue about the remove of the FeatureLocking wrapp=
er
>from geoserver.
> =20
>
No worries,
I doubt it would be removed - it is just that the DataStore API has been=20
looking for something very similar to deal with the reprojection stuff.=20
I am not sure the DataStore API would care about keeping the attributes=20
in a certaint order or not - and GeoServer certaintly does.

>The thing is that ArcSDE DataStore does not implements FeatureLocking ye=
t. I
>did put that wrapper just to deal with that kind of read-only or non-loc=
king datastores,
>since I though there can be more of them out there.
> =20
>
>Now, since geoserver responses directly casts featuresources to
>FeatureLocking objects, I'm getting a ClassCastException.
> =20
>
Say it is not so!
That would certaintly be a bug - all the code I have written uses an=20
instance of opperator first (that is the point of having separate=20
FeatureSource/FeatureStore/FeatureLocking interfaces). Can you please=20
open Jira bug reports on anything bad like this that you find? You can=20
even assign the bug to me :-)  I am writing documentation and would love=20
the distraction.

>In my humilde (and surely inaccurate) thought is, that since I actually =
can
>get SdeFeatureStore to implement FeatureLocking, there should be other
>non-locking featuresources that one may wish to use as read only ones.
> =20
>
I am afraid I did not quite follow you, so I am sure I am inaccurate :-)
If I understand your point - we would like to limit a FeatureStore to be=20
read-only (that is a FeatureSource).

This is a very good point, if I understand correctly. Actually we would=20
have to make the GeoServerFeature*.java wrappers have public=20
constructors again (I am afraid I hid them behind a factory class). I=20
must not have thought this one through

>By the other hand, I think we could benifit from extending the datastore=
 api
>to explicitly get FeatureSources, FeatureStores or FeatureLockings, prov=
ided
>that a given one can be read-only based, for example, on connecting user=
 to
>a database, or filesystem privileges over a file based one.
> =20
>
I understand now, my intention with "getView( Query )" was that it would=20
always be a read-only FeatureSource instance. Used to to handle things=20
like reprojection. The method getFeatureSource( Query ) would be used as=20
an a exact mapping to the DataStore.

I admit this is not well thought out - for instance getFeatureSource(=20
Query ) should return a read-only FeatureSource when the parameters are=20
limitied.  If the user cannot add a complete Feature with all parameters=20
we will not be able to create a new Feature in the DataStore.

This is a long way of saying that Query may already acomplish the needs=20
of the proposed getView. It could be that the only way to get a=20
FeatureSource capablie of write-access or locking is to use a Query with=20
getProperties =3D=3D null !

>By this way, with propper methods on DataStore, we should be able to que=
ry
>the backend about write privileges, with the benefit of exposing  them a=
s
>writeable or not.
> =20
>
Ah - it seems we have arrived at the same conclusion - we need to define=20
the proper methods. Could this situtation be resolved using or extending=20
Query? We are already forced to only provide read-access with using=20
properties or reprojection. Basically if the Query is at all complicted=20
we need to restrict what we return.

>I hope to be explaining me well.
>May be you can tell me is it is usefull to send theese  questions to the
>email list, or if they are already discussed in the time I was not follo=
wing
>the list too much.
> =20
>
By all means send these questions to the list, they have been discussed=20
- but apparently not sufficiently. I am afraid a lot of these issues=20
came up during conversations about reprojection which put most people to=20
sleep. The question is which list - the bug is in GeoServer and the=20
shortfall is in GeoTools?

This is actually a great time to talk about such things as the DataStore=20
API is scheduled for some TLC as it switches over to using Data Transfer=20
Objects for construction.

Cheers and thanks for the feedback,
Jody