Low Found on customer data:
When test case name exceeds 255 chars, the import fails. Several issues here:
1. Import status is cryptic and should be improved:
Time Level Type Description Exception
2010-04-08 12:45:56 fatal bootstrap Bamboo has encountered errors while upgrading. Please resolve these errors and restart Bamboo. Upgrade task for build 1825 failed with exception: null
2. Maybe the test case name should be extended (since we now know it's to short for hierarchical test case names). Note: varchar is limited to 255 chars on some dbs (for example MySQL has to be >=5.0.3). So, it's not as easy as it seems. We could also switch to text from varchar (but we also need to verify db support for that).
3. What to do when such test case is encountered during Bamboo build processsing? Options: truncate, skip.
4. How should it affect the whole import? Options: truncate, skip.
5. Import stopped much later than at the point exception was detected (existing processing threads continued).
I will fix 1 and 5.
I need opinions on 3 and 4. I vote truncate.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BAM-5624] Depending on underlying database, test case import can fail when test case name is too long
> 1. Would it be possible to use string without the length set? How would that be mapped to HSQL, PostgreSQL, MySQL, Oracle by Hibernate?
This would make the import even more database dependent. But you can expect 255 at least in some of the cases.
> 2. Do you think we should implement length checking even if the length limit would be raised to let's say 32k?
No, in such case it would not be necessary - extremely long test case name is most likely a bug in import/export and should be treated as an error. But still, raising the limit may be problematic for some of the dbmses we support.
Currently we are using string with length limited to 255.
1. Would it be possible to use string without the length set? How would that be mapped to HSQL, PostgreSQL, MySQL, Oracle by Hibernate?
2. Do you think we should implement length checking even if the length limit would be raised to let's say 32k?
I'm +1 on increasing the column size of the field. We need to make sure we don't use the field in any indexes, group by statements, since this may cause it some problems.