Hi Myrna,
Thanks for finding this problem. Some comments inline...
On 9/12/11 12:39 PM, Myrna van Lunteren wrote:
Hi,
I was double checking whether changes were needed to the documentation
reflecting the error messages (rrefexcept71493.dita, which gets build
in the source tree and needs to go in the doc tree), expecting no
changes...
But there was a change for DERBY-4437, and looking closer at it, I
have a question.
With revision 1141645 a modification to
java/engine/org/apache/derby/loc/messages.xml was backported to 10.8:
<msg>
<name>2200H.S</name>
-<text>Sequence generator '{0}' does not cycle. No
more values can be obtained from this sequence generator.</text>
+<text>Sequence generator '{0}.{1}' does not cycle. No
more values can be obtained from this sequence generator.</text>
+<arg>schemaName</arg>
<arg>sequenceName</arg>
</msg>
@@ -3433,6 +3434,13 @@ Guide.
<arg>sequenceName</arg>
</msg>
+<msg>
+<name>X0Y85.S</name>
+<text>The Derby property '{0}' identifies a class
which cannot be instantiated: '{1}'. See the next exception for
details.</text>
+<arg>propertyName</arg>
+<arg>className</arg>
+</msg>
+
I believe this means that the non-English messages now get to see a
schema name where they expect a sequence number.
Users will see 'APP' rather than 'APP.MYSEQ' for the 2200H condition.
e.g. in Spanish (messages_es.properties):
"2200H.S=El generador de secuencias ''{0}'' no recorre los elementos.
No se pueden obtener m\u00E1s valores de este generador de
secuencias."
The consequence of this problem is that in non-English locales, users
will see a confusing error message when the legal range for a sequence
or identity column is exhausted. I don't think this situation is likely
to arise in a well-designed application. It is possible that the
application will have so many identity columns and sequences that tech
support won't know which sequence/identity to blame if the confusing
error message pops up. My gut feeling is that this is a rare situation
which will result in some annoyance but it will not be hard for tech
support to figure out what is going on.
I have not tried to test this (yet), but would like opinions on how to
resolve this...
I can think of:
1. undo the backport
This seems to me to be the least attractive option. Revision 1141645
backported all of the work done on this issue. Users have expressed some
frustration about this JIRA and probably don't want to wait for 10.9 for
the scalability improvement provided by this fix. It would be
unfortunate to throw away all of that good work because of a minor defect.
2. remove the message 2200H altogether from the foreign language
files; this should make the English pop up.
I can't say which is less confusing: the garbled error or a message in a
foreign language.
If we are going to edit all of those localizations, the following fix
seems better to me:
Change '{0}' to '{0}.{1}' in all of the localizations. Then the user
will see 'APP.MYSEQ', which is what we want.
3. ignore I noticed this.
This would be my vote this late during the release cycle, provided that
we log a JIRA for the problem so that we can change '{0}' to '{0}.{1}'
in all of the localizations for 10.9.
Thanks,
-Rick
I'm most for 2, but 3 is also possible, if we don't think this is very
important (and it's not going to give a worse error). But perhaps
there's another option/opinion.
I'm going to wait making 10.8.2 until I've heard opinions (or until I
decide what to do)...
Myrna
