It would also be nice if you added javadocs for all the methods added, not just some. I have been striving to maintain consistency in the Content* classes, as well as in the JDBC subclasses, that is a pattern I like to keep on following :). For instance fireFeatureUpdated() has no jabadoc, but fireFeatureAdded() does, etc...
Other then that, great work! -Justin Justin Deoliveira wrote: > Looks like you have been busy Jody. One thing I ask, can you separate > "cleanup" commits. It makes commit logs hard to follow when they are > riddled with formatting changes. I am all for cleaning up the > formatting, just prefer they be done in a separate commit. > > Jody Garnett wrote: >> Turns out the JDBCFeatureReader copy constructor just missed the >> feature source field; all tests now pass with the event notification >> code in. >> >> I am going to go on to write test cases covering the event >> notification code; I think I am being held up over some of the tests >> not working for postgis; perhaps I will switch to hibernate. >> >> Jody >> >> On Sun, May 10, 2009 at 11:27 AM, Jody Garnett <[email protected]> >> wrote: >>> Hi Justin: >>> >>> A bit more debugging: >>> - featureSource is only set to null during a call to cleanup() >>> - the only test that is failing here is the >>> JDBCDataStoreAPITest.testGetFeaturesWriterAdd. This test skips over >>> all the content and then starts adding stuff to the end >>> >>> I suspect that cleanup() is getting automatically called...checking it out >>> now. >>> >>> Okay that was not the case - what happens is when >>> JDBCUpdateInsertFeatureWriter runs off the end and goes to pass over >>> control to an internal JDBCInsertFeatureWriter: >>> if ( !hasNext ) { >>> //update phase is up, switch to insert mode >>> inserter = new JDBCInsertFeatureWriter( this ); >>> return inserter.hasNext(); >>> } >>> The origional JDBCUpdateInsertFeatureWriter has already cleaned up >>> itself; so a null value for dataStore and featureSource are copied >>> over. >>> >>> Aside: I also had to add some implementation to your ResultSetFeature >>> in order to have access to the before and after bounds (I made sure to >>> only calculate the bounds if we actually have anyone at all >>> listening). >>> >>> Jody >>> >>> On Sun, May 10, 2009 at 2:23 AM, Jody Garnett <[email protected]> >>> wrote: >>>> Hi Justin: >>>> >>>> I have added event notification methods to ContentDataStore; and am >>>> having a bit of fun hooking up things in jdbc-ng for testing... >>>> consider the following JDBCInsertFeatureWriter method as an example: >>>> >>>> public void write() throws IOException { >>>> try { >>>> //do the insert >>>> dataStore.insert(last, featureType, st.getConnection()); >>>> >>>> //the datastore sets as userData, grab it and update the fid >>>> String fid = (String) last.getUserData().get( "fid" ); >>>> last.setID( fid ); >>>> >>>> ContentEntry entry = featureSource.getEntry(); >>>> ContentState state = entry.getState( this.tx ); >>>> state.fireFeatureAdded( featureSource, last ); >>>> } catch (SQLException e) { >>>> throw (IOException) new IOException().initCause(e); >>>> } >>>> } >>>> >>>> I expected to have access to the ContentState directly when working; >>>> but JDBCInsertFeatureWriter made me take a long walk to get it ...and >>>> then even that did not work as this.featureSource is null. >>>> >>>> I am calling it a night; I can commit the changes to the >>>> ContentDataStore classes and send you the patch for jdbc-ng. I have >>>> only hooked up the basics (add,modify,remove) and gotten batched >>>> feature events populated; I still need to find out where the >>>> commit/rollback code is and make sure they actually issue the batch >>>> feature event notification. >>>> >>>> Jody >>>> > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
