> Hi Jody, > > Thanks for your answer. However I would need some extra explanations on the > proposed ideas.
Not a problem. > First I will try to reformulate my problem : > On server side, I have lots of datas stored on an Oracle database (lets say > more than a million of entries). Fair enough. > On client side, I would like to access a subset of them (lets say about 10 > entries) and be able to edit them, particularly the spatial data of each > entry (by editing, I mean actions like Delete, Edit Points (for polygons), > Create, ...) yes. > I would like to find a way to retrieve only the interesting entries > (currently applying a Filter works well) and be able to edit them (currently > the only way to edit these datas is to remove the Filter, but I do not want > to get a million of entries on client side). I do not understand why after > applying a Filter, I can not edit anymore the related datas ? Right; the reason is because that is the way I implemented it. Here are a couple reasons: - if you are showing a view based on a filter; and the user changes the attribute the filter is based on what they were working on will vanish - I used a GeoTools "Query" data structure which also has the ability to throw away attributes that are not interesting; as such I could not support the "new" functionality; since the user would not be able to see all the attributes in order to define a new row - So literally the implementation of DataStore.getView( Query ) is not what you need; since it was meeting different requirements then what you want So lets talk about what you do need :-) - You do not want to show all the features (only 10 that match your query). Can we make a filter that is only applied to the Style? You can try this yourself by modifying the advanced page of the Style editor. This would let you show only 10 features; and edit any features (including ones that are not shown right now) - The handling of that "LAYER__DATA_QUERY" parameter is up to us; if you want to change it to mix in with the style; and also make the edit tools aware of it that would be okay? Indeed you could limit this to a check on the EditBlackboard - have it reject anything that does not make it past the filter. - You could also check if it is "just" a Filter; and produce a FeatureStore wrapper (you still have the problem with a user changing an attribute and having their edit "vanish" from the resulting dataset - so your workflow needs work). - If you really just have 10; you may be able to special case a "FeatureID" based filter and make use of that to allow editing even in the face of attribute changes. > Here are some additional comments for the proposed ideas in your last answer >> A couple of ideas: >> - If you want you can look into how this is done; and see if you can >> implement your own FeatureStore wrapper to apply "just" a Filter (rather >> than a Filter or Query as is currently done). > > I do not really understand the difference between applying a filter and > "just" applying a Filter ? Why is this not implemented at the "generic" > level ? I suspect a limitation in the application ... A limitation of time and money it is true; but also one of "workflow" see my comments above; if the user changes the data the feature they are editing may be filtered; no longer giving them a chance to work on it. >> - You could choose to modify your style so that only certain features are >> painted (they would all still be there to be selected and or edited) > The problem is that I do not want to get all the entries from the database, > I really need to filter datas on server side, so I guess this is not an > acceptable solution in my case. Um - you would not get all the features in your database; the rendering code would only request the features that match the style. The style has a filter in it. We are talking about two things: - raw feature store (10 million rows); LAYER__DATA_QUERY filter used to make a wrapper featuresource; style set up to visualize "all" features drawing will fetch 10 rows for drawing. - raw feature store (10 million rows); style set up with a filter will request and draw 10 rows. Note this works because udig only performs the query when needed; both of the above options would result in the same query for visualization. The data is filtered on the server side in both cases. To be clear LAYER__DATA_QUERY only introduces a wrapper; and that wrapper modifies any query by splicing in a Filter into it. It does not store any data; only modify the request being made. It does not handle updates and deletes because I could not figure out how to modify the update and delete calls in a sensible fashion. Perhaps you can have a go at creating a smarter wrapper that handles these operations? >> - A common GIS trick is to make one layer that displays a subset of the >> information; and another layer that is not visible (but is selectedable and >> editable). You could edit the data the one layer; and see the result on the >> first layer > If I understand well, you propose me to keep my read-only layer from which I > would have applied my Filter and create a (temporary ?) layer from which I > would be able to edit new datas ? But this means that I won't be able to > edit existing datas (No "Edit Points" action available for existing > geometries, and no Delete anymore ?). Finally, I wonder how I could specify > that these two layers "share" the same way to write their changes. I am proposing you create a read-write layer; and do not draw it. You should still be able to edit the features on this layer. Indeed any of the features in your database. Under that layer you can show just the features you want; so the users can see where to click to start editing. This is something you can just try out; we may need to talk to jesse to confirm you can edit on layers that are not being rendered right now. Jody _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
