I have updatd the pull request with this change. It turns out that
ReTypingFeatureReader uses the FeatureTypes.equalsExact() static method, so
I have added a check for defaultGeometry to this, plus a test case.
Torben
On Wed, Jan 7, 2015 at 3:35 PM, Jody Garnett wrote:
> I understand your patc
I understand your patch is great for consistency (no chance the two will
get out of sync now) and I agree that it is hard to write a test case
before (it involves the type of the file changing on disk after the
datastore has already been created).
Can you also patch the ReType code to respect the
Here is a pull request fixing the retyping problem:
https://github.com/geotools/geotools/pull/668
Because the issue only crops up sporadically, I am not sure I can create a
usefull test case...
Torben
On Wed, Jan 7, 2015 at 11:12 AM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
> I app
I appear to have found a deeper root cause of this problem and it looks
like it does not actually have much to do with locking.
My origional thoughts about the cause of the error appear to be in error -
this particular instance is correct in failing here as that is what the
test in question is inte
Oops, it looks like ContentState tracks DiffTransactionState, so the
DiffContentFeatureWriter can actually access the DiffTransactionState via
the ContentState. While this invalidates some of my previous points, it
still might be worthwile to consider storing the flag in ContentState,
since much of
Following along here:
> Adding an extra isClosing field to DiffTransactionState seems the cleanest
> approach.
>
Using this method, we give the writer in DiffTransactionState the
transaction.
This transaction gives the lock writer the correct authorizations to pass
the checks
The isClosing field
I considered clearing the authorizations before calling all the
TransactionState.close() methods, but it seems like too risky a change.
Additional thoughts / discussion inline:
This is a tough problem as we have no good way to preserve encapsulation.
> It would be nice to InProcessLockingManger c
This is a tough problem as we have no good way to preserve encapsulation.
It would be nice to InProcessLockingManger check writer implemented an
interface, or had some extra state we could set, allowing it to know we
were at then end of a commit.
Getting access to an "unwrapped" writer from Conten
In attemting to provide the writer with the correct transaction, I ran into
a number of test failures relating to transaction independance. While I
have not thoroughly traced these failures, this suggests that using the
same method as AbstractDataStore (an unwraped internal writer) may be the
best
