GeoTools2 module build report 20060131
gt2:referencing cleaned, compiled, tested, INSTALLED 2357
gt2:sample-data cleaned, compiled, tested, INSTALLED 2357
gt2:coverage cleaned, compiled, tested, INSTALLED 2357
gt2:api cleaned, compiled, tested, INSTALLED 2357
gt2:main cleaned,
The answer is that WFS only works from a transaction - not for
Transaction AUTO_COMMIT
Howdy,
http://jira.codehaus.org/browse/GEOT-804
I'm having trouble with getCount for WFS. It's throwing a class cast
exception in AbstractDataStore.diff(Transaction) because the state of
the transaction i
Jody is correct, we decided to not implement this (unless there is a real transaction), because the only posible implementation for 1.0 is a feature-scan ... so left it up to the user.
I don't think we defined an action for AUTO_COMMIT, but -1 sounds correct as a default value for unknown.
I c
View results here ->
http://geovista16.geog.psu.edu/cruisecontrol/buildresults/geotools_current?log=log20060201141939
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX s
David Zwiers wrote:
Jody is correct, we decided to not implement this (unless there is a
real transaction), because the only posible implementation for 1.0 is
a feature-scan ... so left it up to the user.
I don't think we defined an action for AUTO_COMMIT, but -1 sounds
correct as a default
Thanks Cory,
Yah, the idea would be to refactor the logic out, and pass in a version strategy. The 1.0 code would contain the same logic, but the 1.1 code would have a few more smarts, like sending out a getCount call (notice, this may not always be required ... in particular if there is an activ
