Daniel John Debrunner wrote:
Mamta Satoor wrote:
Dan, I am responding to this without thinking about a whole lot but
wanted to put it out. With this scheme of putting collation inside the
existing character type, are we going to impact the performance of
Derby's default collation which is UCS_BASIC? The goal from the
beginning has been to leave current SQLChar implementation as unaware
of the new collation requirement as possible. It's possible that your
suggestion does take that into account but I thought I would ask the
question if this approach is going to impact the performance of
existing Pre 10.3 upgraded to 10.3 or new 10.3 databases created with
default collation?
Not sure what you mean by "putting the collation inside the existing
character type", but I think there will be no performance impact on
SQLChar, I'm assuming all the setup is done when the activation is
initialized. It's just flipping which runtime class does the comparisons.
Again I think both mamta and I did not understand that your proposal
still contained 4 new classes which will extend the 4 basic char classes
and allow the flipping at runtime.
Dan.
