|
If you were logged in you would be able to see more operations.
|
|
|
| Resolution Date: |
26/Apr/07 12:23 PM
|
|
DataDictionaryImpl.getSystemSQLName() may generates names on the form SQLYYMMDDHHMMSSmmN where mm is in 10 milliseconds and N is number to avoid collisions with 10 milliseconds. The name was probably generated this way to fit into the 18 caharcter limit of constraint names in older derby versions. However, if a getSystemSQLName() is called 12 hours after a call on the same date (e.g at 01:00:00 and 13:00:00), which is unlikely but not very unlikely, a duplicate name is generated, since the HH-part is filled by the call
generatedSystemSQLName.append(twoDigits(calendarForLastSystemSQLName.get(Calendar.HOUR)));
and Calendar.HOUR implementes the pretty stupid idea that there are only 12 hours. It was definitely Calendar.HOUR_OF_DAY which gives you the hour for a 24-hour clock that should have been used.
|
|
Description
|
DataDictionaryImpl.getSystemSQLName() may generates names on the form SQLYYMMDDHHMMSSmmN where mm is in 10 milliseconds and N is number to avoid collisions with 10 milliseconds. The name was probably generated this way to fit into the 18 caharcter limit of constraint names in older derby versions. However, if a getSystemSQLName() is called 12 hours after a call on the same date (e.g at 01:00:00 and 13:00:00), which is unlikely but not very unlikely, a duplicate name is generated, since the HH-part is filled by the call
generatedSystemSQLName.append(twoDigits(calendarForLastSystemSQLName.get(Calendar.HOUR)));
and Calendar.HOUR implementes the pretty stupid idea that there are only 12 hours. It was definitely Calendar.HOUR_OF_DAY which gives you the hour for a 24-hour clock that should have been used.
|
Show » |
|
Bug
Closed
Major
DataDictionaryImpl.getSystemSQLName() may generate duplicates
