Mike Matrigali <[EMAIL PROTECTED]> writes: > Mamta A. Satoor (JIRA) wrote: >> [ >> http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420145 >> ] >> >> Mamta A. Satoor commented on DERBY-1330: >> ---------------------------------------- >> >> Mike responded following on the mailing list >> <quote> >> I do not believe you can count on the order of a HashMap, different >> JVM's may use different hash algo's which may result in different orders >> when you ask for the full list. I have seen this behavior in queries >> which use hash nodes in derby (I believe we first noticed a difference >> between j9 and other jvm's). In that case we added order by's as >> necessary to the tests, as either order of results was correct from >> SQL point of view. >> >> In your case is the order a code problem, or just a testing issue? >> </quote> >> >> First of all, thanks Mike for your response. >> >> As to your question, the order is not a testing issue because test >> is simply trying a scenario where a user is trying to create a >> object based on more than one object on which the user doesn't have >> access to. And depending on how items got into HashMap, the test >> fails with privilege error on one object vs the other. So, in this >> case, the order is a code problem. > > If the order of the error is not documented, then I am not sure it > is a code error. Sort of similar to the fact that on different > jvm's derby will return rows in different orders for the same db, > same query (unless a specific order by is used). I would define it > as a test problem, as the test assumes a specific error where either > of 2 errors is valid.
I agree. Since the SQL state is equal in the two cases, I think a sed script that strips everything but the message would be OK. Something like this in grantRevokeDDL_sed.properties: substitute=^ERROR ([^:]*):.*$;ERROR: Failed with SQLSTATE $1 > The code could use some sorting mechanism to guarantee an ordering, but > it would have to be careful about the key (object id's could also vary > from machine to machine, or time to time). Doing so would likely mean > more memory and more code, doesn't seem worth it to me for this case - > anyone think so? Perhaps a LinkedHashMap would do the trick, but I agree, I don't think it's worth it. -- Knut Anders
