db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: re 10.8.2 / DERBY-4437
Date Mon, 12 Sep 2011 20:37:46 GMT
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.

> 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

View raw message