Going to start a new thread to reply as the other one was getting full.
> Glancing over those docs, I don't think we'll have any problems with it.
> It's a good 'standard' to shoot for.
Agreed; I am more interested in the tutorial part right now. We can address the
other stuff when the code works.
> I do have some more questions about writing-a-csv. I finally got into
> implementing the CSVFeatureWriter and I'm not sure how to fit it into
> ContentFeatureStore, etc. Allow me to ramble a bit..
Yep; the questions are what we need to sort out.
> For starters, I'm working on this API:
>
> SimpleFeatureStore.modifyFeatures(String name, Object
> attributeValue, Filter filter).
> My understanding of that API is that the resulting csv file will contain
> the same rows as before, in the same order, but with the specified
> attribute updated in just those rows that match the filter. Correct?
Correct.
> If so, let's examine the implementation of modifyFeatures in
> ContentFeatureStore:
>
> FeatureWriter<SimpleFeatureType, SimpleFeature> writer =
> getWriter(filter, WRITER_UPDATE);
> try {
> while (writer.hasNext()) {
> SimpleFeature toWrite = writer.next();
> for (int i = 0; i < type.length; i++) {
> toWrite.setAttribute(type[i], value[i]);
> }
> writer.write();
> }
> } finally {
> writer.close();
> }
>
> It gets a FeatureWriter that, presumably, delivers just those rows that
> match the filter. But if the writer actually writes out the modified
> rows to a file, then you end up with just the modified rows and not the
> rest.
The intension is to writes out the other ones as well; that is what the
WRITER_UPDATE "flag" is for. I think writer update will apply a wrapper around
the "raw" feature writer you have supplied.
Let me look.
Okay In ContentDataStore we have the following method:
public final FeatureWriter<SimpleFeatureType, SimpleFeature> getWriter( Query
query, int flags ) throws IOException {
query = joinQuery( query );
query = resolvePropertyNames(query);
FeatureWriter<SimpleFeatureType, SimpleFeature> writer = getWriterInternal(
query, flags );
//TODO: apply wrappers
//TODO: turn locking on / off
LockingManager lockingManager = getDataStore().getLockingManager();
return ((InProcessLockingManager)lockingManager).checkedWriter(writer,
transaction);
}
See the TODO - this is the part where I need to work with you in order to pass
test cases.
I need to add something similar to:
if ( (flags | WRITER_UPDATE) == WRITER_UPDATE ) {
writer = new FilteringFeatureWriter( writer, filter );
}
The wrapper class FilteringFeatureWriter takes care of skipping/writing any
rows that do not need to be modified during the call to hasNext().
> Alternatively, the writer could operate on an in-memory structure
> containing all the rows and not write out to a file until the whole
> modifyFeatures is done.
That is not our style; if the user wants to load stuff into memory they can do
that themselves, we don't want to force their hand.
> It seems like the only way to make it work is to
> override modifyFeatures in CSVFeatureWriter and make it work for the
> particular limitations that CSV files require, but that seems not-great
> either.
What do you think of the wrapping approach shown above? You could override the
getWriter method in CSVDataStore now in order to experiment with wrappers; and
then we could copy it into ContentFeatureStore when you are happy it works.
There are a large number of "wrappers" like this to perform common tasks.
The previous tutorial had the details and there is a bit more the the user
manual and javadocs.
- http://docs.geotools.org/latest/userguide/library/main/internal.html
-
http://docs.geotools.org/latest/userguide/tutorial/advanced/abstractdatastore.html#low-level-optimisation
(shows how the previous AbstractDataStore applied wrappers around a
FeatureWriter)
- http://docs.geotools.org/latest/javadocs/org/geotools/data/FeatureWriter.html
In particulary:
DiffFeatureWriter - used to handle transaction stuff (this does load only the
changes into memory - similar to what you described)
EmptyFeatureWriter - used for Filter.EXCLUDES or Query.NONE
FilteringFeatureWriter - used as you have discovered above
>
> Suggestions?
>
> Thanks,
>
> Lee
--
Jody Garnett
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
