Java client api expression .. unable to query and retrieve workitems for custom attribute value from repository "Incorrectly typed parameter submitted to query"

 I'm stumped.  I've asked the Work Items team to help out.

Thanks  . Here  is an  interesting find . I am able to query  for  Enumerated  custom attributes.  This code work  for retrieving  a custom attribute  called   D4_PROCESSINGSTATUS  where the  attribute is "UNCLASSIFIED"

skipped the  resolve  enumeration  activity to get  the   "UNCLASSIFIED"  status and  its handle is  processingstatusliteral.getIdentifier2() below

 String   attributeprocessstatusId = "D4_PROCESSINGSTATUS";
   IQueryableAttribute PS = attFactory.findAttribute(projectArea,attributeprocessstatusId , auditableClient, null);
   AttributeExpression ExpressionPS = new AttributeExpression( PS, AttributeOperation.EQUALS,  processingstatusliteral.getIdentifier2());

I will wait on  the response  from the other team  about  supplying the string value for string parameter

Nick,
     Were  you able to  get anything back from the  WorkItem  team?

No, sorry, but I've pinged them again. 

For the enum query, is that the only attribute you're querying on?  Maybe in the other query it's getting confused by having two terms (though the way you're constructing it looks OK to me).  Can you simplify the problematic case to have just the string term?

Nick,
I  am back to this problem  again. I had to put project  on hold  for a few months but now I am "really" desperate to get  it working .I simplified the case .Using  different fields but same error. The custom  attribute field is D4Activity and the value  to query  is "r_svt"
IQueryableAttributeFactory lattFactory = QueryableAttributes.getFactory(IWorkItem.ITEM_TYPE);
    IQueryableAttribute IQACTIVITY=lattFactory.findAttribute(projectArea,"D4ACTIVITY", auditableClient, null);
    Expression D4ActivityExpression = new AttributeExpression(IQACTIVITY,
            AttributeOperation.EQUALS, "r_svt");
results =queryClient.getResolvedExpressionResults(projectArea,D4ActivityExpression, IWorkItem.FULL_PROFILE);
 results.setLimit(Integer.MAX_VALUE-1);

com.ibm.team.repository.common.TeamRepositoryException: Incorrectly typed parameter submitted to query; Parameter 0 was class java.lang.String but com.ibm.team.repository.common.UUID was expected

Nick
   I may have figured out  the problem.
My custom attribute was   LARGE STRING ..   i  changed to  SMALL  STRING  
 I am  still testing  but  I think I can now  query based on that custom attribute ....

Thanks  for all your assistance

Hi Mark, good to hear that you've found something that appears to work.  I'm still puzzled, though, since I'd expect large string and small string to work similarly, i.e. the expected value in a query would be a String in both cases, not a UUID.

Nick
I came  across  this  doc  that suggests the Large strings cannot be used in simple  queries


String
String attributes, available in three sizes: Small String (250 bytes when using UTF-8 encoding), Medium String (1000 bytes) and String (32768 bytes). String can only be queried by fulltext.

If that is indeed the problem, I'd expect it to fail with a clearer error message to that effect, not complain about a type mismatch with UUID.  If you think that's the problem, please open a work item against Work Items.

I have done enough  testing since yesterday to confidently  say   it is the problem . I have created  2 same environments except  the same  attribute has   SMALL  STRING  in the case  that works and  LARGE STRING  where  it fails .
Moreover  I noticed that  when  custom att  is LARGE STRING   it is not available as  queryable  attribute in the RTC clients  unless  you are doing full text queries

Where to create the defect?

If it's working now for small strings, but failing for large string, then that does suggest the problem is due to large strings not being indexed like regular attributes, just for full text search.  If the failure mode is that it complains that it's not a UUID, then that's a bug.  You can open a work item against RTC at:

Agreed, The  error is completely  misleading ..... and clearly out of place . I will open the defect asap.
 Thanks