Sorry, I forgot to mention that I already did put in the FilteringFeatureWriter
and it works fine. Perhaps too fine. Or maybe it just needs more work. I like
the idea of chaining together various wrapped writers, but I just don't see how
the current set of them can work.
Can we chat sometime on IM, or is that what IRC is for? I'm traveling at the
moment but should be online later tonight (I'm in the US, west coast).
Lee
Sent from my Verizon Wireless Phone
----- Reply message -----
From: "Jody Garnett" <[email protected]>
Date: Wed, May 11, 2011 3:46 pm
Subject: ContentFeatureStore for CSV tututorial
To: "geotools dev" <[email protected]>, "lee-verizon"
<[email protected]>
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
