[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mylar-dev] jira query synchronization and others
|
Eugene,
After the query happens the timestamp is set on the TaskRepository,
then when the query is run again that timestamp is retrieved from the
TaskRepository and used in the next query as the start date/time (at
least for Bugzilla).
Are you proposing that we switch to using a local timestamp then
generate the necessary relative query for these repositories? This
could work, but might increase the amount of unnecessary retrievals of
task data.
-Rob
On 2/1/07, Eugene Kuleshov <eu@xxxxxxxx> wrote:
Rob,
From what I read in the code, that workaround is used to get timestamp
for saving last update (after executing query), while current time
(before executing query) is calculated on the local timestamp. That does
not work for JIRA, which is using relative time intervals where you say
-5m from now. From bugzilla help, it seems like it also allows similar
option for querying issues changed in required time frame:
----
Specify the start and end dates either in YYYY-MM-DD format
(optionally followed by HH:mm, in 24 hour clock), or in relative
dates such as 1h, 2d, 3w, 4m, 5y, which respectively mean one hour,
two days, three weeks, four months, or five years ago. 0d is last
midnight, and 0h, 0w, 0m, 0y is the beginning of this hour, week,
month, or year.
----
But it doesn't seem like it does support minute intervals, but perhaps
we can make it repository specific, or find some way to get the current
time from the repository.
regards,
Eugene
Robert Elves wrote:
> The reason for this weirdness is because we need to send a start date
> that is relative to the server (not a calculated date based on the
> local pc's time). If we try to use a local date inevitably we don't
> have the time zone or the local clock is out of sync with the servers
> which causes missed incomings. So we need a valid time stamp from the
> repository for this to work.
>
> Unfortunately, bugzilla doesn't return a timestamp equivalent of the
> actual query execution time (the NOW) so we've implemented the work
> around you see with getting the time stamp from the most recently
> changed task returned.
>
> It isn't pretty but works. If I've overlook a better solution to this
> problem please let me know! :)
>
> -Rob
>
>
>
>
> On 2/1/07, Eugene Kuleshov <eu@xxxxxxxx> wrote:
>> Rob, Mik,
>>
>> Can one of you look at the
>> RepositorySynchronizationManager.GetChangedTasksJob.run()
>>
>> I don't understand the logic of that thing. For instance, why does it
>> only sets the last repository sync time only if there was changed tasks?
>> And also, why it is using the mostRecentTimeStamp from the changed
>> tasks?
>>
>> The problem is that mostRecentTimeStamp is in "who knows what"
>> timezone and for JIRA connector we can't construct reliable offset from
>> the current date.
>>
>> So, I think that repository setSyncTime() should be set based on the
>> local timestamp and it should be also set when there is no updated
>> tasks.
>>
>> regards,
>> Eugene
>>
>>
>> _______________________________________________
>> mylar-dev mailing list
>> mylar-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mylar-dev
>>
>
>
_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev
--
Robert Elves
Mylar committer, http://eclipse.org/mylar
