It's all about the answers!

Ask a question

[closed] Doing timestamp comparisons with "modified"


Ernest Crvich (19211817) | asked May 13 '09, 9:47 a.m.
closed Jun 01 '16, 2:21 a.m. by Ralph Schoon (60.9k33643)
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?

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
Patrick Streule (4.9k21) | answered May 14 '09, 2:40 p.m.
JAZZ DEVELOPER
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

permanent link
Yue CDL (1611) | answered May 03 '11, 9:25 a.m.

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!

permanent link
guoping chen (191014) | answered May 31 '16, 11:06 p.m.
I have the same question. Could anybody resovle the problem? Thanks in advance.

Comments
Ralph Schoon commented Jun 01 '16, 2:21 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.