Jody Garnett wrote: > Save the history for a subpage; limit the proposal page to what you want > to see done (same advice I gave Gabriel). Can do... its just so hard... :) > > The actual content seems fine, review gabriel's submission for admiting > that getReader and getWriter exist (it is listed as a design goal). > > The fine details: > - create a jira to track this one > - don't bother with getFeatureWriterUpdate( Query ) it is only filter is > needed Not sure I agree. What if you only want to update particular attribute. You could get some savings at the data access level. But i admit... we dont ever really do this now. I could go either way. > - I like getWriterInset() - I had written down getWriter( append ) with > the understanding it would handle the Filter.INCLUDES and insert case
> - can I have my visitor method ;-) Oh yeah... you sure can :). > Suggestions: > - can we have a seperate interface for inserting content; this dual > purpose FeatureWriter is a waste of time, space, > Thinking of FeatureWriter and FeatureInsert here and complexity. Yeah I like this idea... Using the same interface for dual purpose is kind of strange, but it would be a significant api change... so would most likely break backwards compatability. > > Useless history: > - the reason I have stuck by FeatureCollection here is I want to make > sure our low level api (FeatureReader, FeatureWriter etc...) can support > high level constructs of *some* kind; as we will need this to implement > associations in a lazy manner over on the Feature/FeatureType side of > the fence. I would worry about our low level api first. We can always wrap it up in an abstraction later. Doing now just confuses things imho. > > Cheers, and nice proposal. > Jody > >> I have been giving a bit of rough feedback to others for their >> proposals so here is a chance for people to get back at me. I finally >> got around to writing up my ideas on how to cleanup data access with >> regard to feature collection. >> >> http://docs.codehaus.org/display/GEOTOOLS/DataStore+Cleanup >> >> -Justin >> >> > > > !DSPAM:4007,47aa5530239351804284693! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
