How detect if long multi-line values in OSLC ClearQuest API has been truncated?
Hi,
this is related to this: http://www-01.ibm.com/support/docview.wss?uid=swg21590934
evidently the string response from the REST query will be truncated to 2000 characters (or specified value on server) for multi-line fields. I wonder what the work around for this is. There has to be some way to determine if the values recieved are valid or not (otherwise one might just as well turn off the possibility to query a mult-line field).
- Is it possible to get the com.ibm.rational.cm.web.component.max.multiline.text.length=2000
by a REST Query?
- is there a field/property that one might read out that tells that the field is larger than the truncation limit
- is there anything in the response that indicates that a field has been truncated?
Accepted answer
What's your use case? If you absolutely need to get the full content of a multiline text, you can set the parameter to 0, although you need to understand what potential risk it brings.
Comments
The CQ server settings is unfortunately outside my control.
I'm a Configuration Manager at a subcontractor to a customer. The customer use CQ and we use another issue tracker system (JIRA). I wrote a synchronize routine to update our issue tracking system with their information from their Clear Quest server. This was previously a tedious manual task of comparing, copying and pasting information from the CQ web interface. I wanted to automate it. It seemed to work well, until I noticed something was missing in an issue description on our side... the customer is a large multinational corporation so I think there isn't even a remote chance of getting them to update their CQ server properties, especially due to this comment "Adjust this value to allow larger or smaller numbers of characters. Note: You may run into server internal errors in some complicated schemas with a large value. " in the ClearQuest OSLC CM REST API specification.
Well, that's quite unfortunate. Synchronizing between two different systems usually requires some compromise. If nothing can be changed on the CQ side, I think you can consider a multiline text with length of 2000 as a "suspect". Basically, whenever you detects such a field in a CQ record, you should mark it down for later review.
Thanks for the clear answers to my questions. The workaround is as you mentioned, to flag suspicious issues.
Modern applications such as the Jazz family applications use internal APIs most of the time, and only utilize OSLC/REST APIs when communicate between applications. Which may or may not have the same issue. Performance issue is always a challenge though so we almost always have to "cap" something. For example, we may limit he result set of an OSLC query to a certain number.
ClearQuest is based on a very old architect - it's essentially a 32 bit Windows application. The OSLC/REST capability is added later on so realistically it cannot provide "optimum" performance in this regard.