Daniel John Debrunner wrote:
Aren't there two separate (but related) issues here?
1) What Derby stores on disk (the extra number of characters stored)
2) How Derby serialized XML values back to an application (the test
counting issue).
Serialization of XML values can be expensive, so in order to ensure that we only
do it once, Derby serializes the data once and writes the serialized version of
it to disk. Then when we fetch it back we just read it from disk and return it
to the app. So due to the way this is implemented, this is actually just one
issue. Maybe that implementation decision needs to be revisited, though...
Seems on output (XMLSERIALIZE) generating the correct line endings for
the platform makes sense
But there's no "generation" here because the data is being read directly from
disk and returned to the user.
the test should be smarter than counting raw characters.
That's the other option. I think there are clob comparison methods in JUnit so
we could just use that to make the test smarter. But that falls into option "2"
approach of avoiding the problem by changing the test. If that's what we want,
I can certainly do it. But the serialization itself seems like something to
address...or at least, something on which we agree to not address.
Army
