[Building Sakai] Problem with clustering??

[Matthew Jones]

Yea, it probably needs to stay DATE or TIMESTAMP. The original suggestion
and fix for the problem might not work.

The code runs this query
select SERVER_ID from SAKAI_CLUSTER where SERVER_ID != <this server> and
DATEDIFF('ss', UPDATE_TIME, CURRENT_TIMESTAMP) > 600;

I have a feeling that DATEDIFF on comparing CURRENT_TIME against a field
that has is stored as TIMESTAMP WITH TIMEZONE (UPDATE_TIME) might be
causing a problem?

On Wed, Sep 26, 2012 at 10:42 PM, Omer A Piperdi <omer at rice.edu> wrote:

> Thanks for the info. We have TIMESTAMP WITH TIME ZONE in the database
> I am just wondering why clustering is different from session or event
> table... because we also converted colums in them to TIMESTAMP but they
> have correct value..
>
> Omer
>
> On 9/26/2012 7:34 PM, Seth Theriault wrote:
>
>> On Wed, Sep 26, 2012 at 6:33 PM, Matthew Jones <matthew at longsight.com>
>> wrote:
>>
>>  The intention was to fix cluster problems when daylight savings time
>>> changed, but it seemed like it would break more than it would fix. He
>>> assured me that there was research done that all of this was safe, but I
>>> don't have any way to test on Oracle (and not much vested interest in
>>> Oracle) so accepted this.
>>>
>> Looking back at KNL-725, I am the source of the research and therefore
>> probably the problems that have occurred. I clearly missed the
>> subtleties involved and opnly verified whether the conversion from
>> DATE to a TIMESTAMP variant would be OK for the data preservation.
>>
>> This was a critical error on my part.
>>
>>  It's very likely it should have been converted to TIMESTAMP WITH LOCAL
>>> TIME
>>> ZONE. Then it would have been at least equal to Mysql.
>>>
>> This is correct and goal of alignment is good. The fix is a different
>> story, especially if you have older data and you are expecting UTC.
>> I'd have to look more closely but it might be possible to convert the
>> affected data to UTC and then alter the column type (might need
>> external temporary tables for this). Then again, in a large
>> installation, this could affect millions of rows.
>>
>> On a different note, I have scheduled Sakai restarts on the "DST
>> Sundays" for the last few years to workaround this problem in Oracle.
>>
>> Seth
>>
>> !DSPAM:2294,**50639f1f125891258298333!
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120926/8c53e2a4/attachment.html