Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

[closed] Doing timestamp comparisons with "modified"

I'm getting weird results from trying to do queries based on the last modified time of work items. Here's a code snippet where I add the timestamp comparison into my Term (which contains other field comparisons as well, and seem to work fine):

///////////////////////////////////////////////////////

IAuditableClient auditableClient = (IAuditableClient)
getRepository().getClientLibrary( IAuditableClient.class );

IQueryableAttributeFactory factory =
QueryableAttributes.getFactory( IWorkItem.ITEM_TYPE );

IQueryableAttribute recAttr = factory.findAttribute(
getProjectArea(), IItem.MODIFIED_PROPERTY, auditableClient,
null );

Timestamp timeStamp = getLastPollDate();

AttributeExpression recExpr = new AttributeExpression(
recAttr, AttributeOperation.AFTER, timeStamp );

term.add( recExpr );

///////////////////////////////////////////////////////

The problem is that the "AFTER" comparison seems to always be true no matter what timestamp I use (i.e., a time before or after the actual "modified" value of a given work item). In fact, I can change that operator to "BEFORE" or even "EQUALS" and I always get the same list of records as if I didn't even add this expression into the term. The only way I don't end up getting any records back is with the "NOT_EQUALS" comparison...which doesn't make any sense at all to me.

Note that the Term was originally constructed with Operator.AND.

So, how do I query work items whose last modification was after a certain date/time?

0 votes


The question has been closed for the following reason: "Problem is not reproducible or outdated" by rschoon Jun 01 '16, 2:21 a.m.


3 answers

Permanent link
The problem is that the "AFTER" comparison seems to always
be true no matter what timestamp I use (i.e., a time before or after
the actual "modified" value of a given work item). In
fact, I can change that operator to "BEFORE" or even
"EQUALS" and I always get the same list of records as if I
didn't even add this expression into the term. The only way I don't
end up getting any records back is with the "NOT_EQUALS"
comparison...which doesn't make any sense at all to me.

Note that the Term was originally constructed with Operator.AND.

So, how do I query work items whose last modification was after a
certain date/time?

As we currently support only dates as work item fields, there is some
magic here that causes this odd behaviour. E.g. EQUALS checks for the same
day, as this is what we generally support in queries. It would make sense
to add operators that don't have this behaviour.

You could resort to the lower-level Ast query API and formulate your
queries, if you don't need Query Editor support for the queries you
construct.

--
Regards,
Patrick
Jazz Work Item Team

0 votes


Permanent link

As we currently support only dates as work item fields, there is some
magic here that causes this odd behaviour. E.g. EQUALS checks for the same
day, as this is what we generally support in queries. It would make sense
to add operators that don't have this behaviour.

You could resort to the lower-level Ast query API and formulate your
queries, if you don't need Query Editor support for the queries you
construct.

--
Regards,
Patrick
Jazz Work Item Team


Hello,

Is there any guide to use the Ast query API? We have strong needs to query the changed WorkItems in minutes, not in hours or days. Any clue? Thanks very much!

0 votes


Permanent link
I have the same question. Could anybody resovle the problem? Thanks in advance.

0 votes

Comments

If you have a question, I would suggest to state it as a new question. This question is from 2009 - 6 years old. I will close it.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,950

Question asked: May 13 '09, 9:47 a.m.

Question was seen: 5,925 times

Last updated: Jun 01 '16, 2:21 a.m.

Confirmation Cancel Confirm