Gabriel Roldán wrote:
ok. thanks a lot
Cool 
gabriel.
P.S.: Jody, I have an issue about the remove of the FeatureLocking wrapper
from geoserver.
No worries,
I doubt it would be removed - it is just that the DataStore API has been looking for something very similar to deal with the reprojection stuff. I am not sure the DataStore API would care about keeping the attributes in a certaint order or not - and GeoServer certaintly does.
The thing is that ArcSDE DataStore does not implements FeatureLocking yet. I
did put that wrapper just to deal with that kind of read-only or non-locking datastores,
since I though there can be more of them out there.Now, since geoserver responses directly casts featuresources to
FeatureLocking objects, I'm getting a ClassCastException.
Say it is not so!
That would certaintly be a bug - all the code I have written uses an instance of opperator first (that is the point of having separate FeatureSource/FeatureStore/FeatureLocking interfaces). Can you please open Jira bug reports on anything bad like this that you find? You can even assign the bug to me I am writing documentation and would love 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.
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 read-only (that is a FeatureSource).
This is a very good point, if I understand correctly. Actually we would have to make the GeoServerFeature*.java wrappers have public constructors again (I am afraid I hid them behind a factory class). I 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, provided
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.
I understand now, my intention with "getView( Query )" was that it would always be a read-only FeatureSource instance. Used to to handle things like reprojection. The method getFeatureSource( Query ) would be used as an a exact mapping to the DataStore.
I admit this is not well thought out - for instance getFeatureSource( Query ) should return a read-only FeatureSource when the parameters are limitied. If the user cannot add a complete Feature with all parameters 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 of the proposed getView. It could be that the only way to get a FeatureSource capablie of write-access or locking is to use a Query with getProperties == null !
By this way, with propper methods on DataStore, we should be able to query
the backend about write privileges, with the benefit of exposing them as
writeable or not.
Ah - it seems we have arrived at the same conclusion - we need to define the proper methods. Could this situtation be resolved using or extending Query? We are already forced to only provide read-access with using properties or reprojection. Basically if the Query is at all complicted 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 following
the list too much.
By all means send these questions to the list, they have been discussed - but apparently not sufficiently. I am afraid a lot of these issues came up during conversations about reprojection which put most people to sleep. The question is which list - the bug is in GeoServer and the shortfall is in GeoTools?
This is actually a great time to talk about such things as the DataStore API is scheduled for some TLC as it switches over to using Data Transfer Objects for construction.
Cheers and thanks for the feedback,
Jody