[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374158#comment-16374158 ] Hudson commented on SQOOP-3288: --- SUCCESS: Integrated in Jenkins build Sqoop-hadoop200 #1150 (See [https://builds.apache.org/job/Sqoop-hadoop200/1150/]) SQOOP-3288: Changing OracleManager to use CURRENT_TIMESTAMP instead of (maugli: [https://git-wip-us.apache.org/repos/asf?p=sqoop.git&a=commit&h=a7f5e0d298ffbf8e674bd35ee10f2accc1da5453]) * (edit) src/java/org/apache/sqoop/manager/OracleManager.java > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374132#comment-16374132 ] ASF subversion and git services commented on SQOOP-3288: Commit a7f5e0d298ffbf8e674bd35ee10f2accc1da5453 in sqoop's branch refs/heads/trunk from [~maugli] [ https://git-wip-us.apache.org/repos/asf?p=sqoop.git;h=a7f5e0d ] SQOOP-3288: Changing OracleManager to use CURRENT_TIMESTAMP instead of SYSDATE in case of incremental import to make the process session time aware (Daniel Voros via Attila Szabo) > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371674#comment-16371674 ] Daniel Voros commented on SQOOP-3288: - Great, thank you [~maugli]! > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371609#comment-16371609 ] Attila Szabo commented on SQOOP-3288: - [~dvoros], Ohh yeah! You're right! And applying the proper timezone was fixed by me in -SQOOP-3071-... My old memory... Approved. Let me sign it on the review ticket as well! Cheers, [~maugli] ps: Thanks for the b part of the explanation, but that was clear already. But thanks! > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371594#comment-16371594 ] Daniel Voros commented on SQOOP-3288: - [~maugli], oh I've see, sorry I didn't get your point! I believe we won't face the problem you've described, because we're not setting the time zone based on the machine that's running the import. We're always using the time zone set via 'oracle.sessionTimeZone' and fall back to 'GMT', see [here|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L415-L418]. I hope this answers your question! Also, let me point out, that the part this change affects is only run when getting the next last-value for an incremental import ({{ImportTool#initIncrementalConstraints() -> SqlManager#getCurrentDbTimestamp() -> OracleManager#getCurTimestampQuery()}}). It won't affect how we're dealing with date/time fields anywhere else. > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371561#comment-16371561 ] Attila Szabo commented on SQOOP-3288: - [~dvoros], You're arguments are absolutely valid, maybe I've not phrased my concerns correctly: Both of CURRENT_TIMESTAMP and LOCALTIMESTAMP fits us, I'm glad we agree in this, and I'm also pretty much accepting that you've chosen the first one (BTW: fair enough arguments!). The problem is the following: Before your patch the behavior is the following: Any timezone, and time is set in the Oracle's OS, we're using that. So regardless which node of the cluster we're executing the import job, the result will be the same. After your patch it's great we would not depend on the ORacle OS time anymore, though the result would differ from machine to machine if the cluster's timezones are mixed (if I'm not mistaken!). So if somehow we're not enforcing setting the session time, or converting and comparing the times in a timezone aware way, the new solution could even result in "strange" results. Do you see any way to ensure that e.g. everything (both last and current times) is compared in a timezone aware way? Or are my concerns are "too paranoid"? Thanks, [~maugli] > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371502#comment-16371502 ] Daniel Voros commented on SQOOP-3288: - [~maugli] it's the other way around. We were getting the OS time before, that's what this patch is supposed to fix. (Also, please note, that we were not relying on the time of the OS running the sqoop job, but the OS running Oracle.) > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371491#comment-16371491 ] Attila Szabo commented on SQOOP-3288: - Hey [~dvoros], The reason why I'm a bit concerned: I've faced already clusters where a specific node was in a very different timezone, than the rest of the cluster. Executing job from that node would end up in different result, than from the others. Do we expect this behaviour? Do we really want to depend on the OS time? Thanks, Attila > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371480#comment-16371480 ] Daniel Voros commented on SQOOP-3288: - [~maugli], I've attached added the link to the review request. Sorry about the fix version. The problem isn't time-zone awareness only, but getting the OS time instead of the Oracle session time. This leaves us with CURRENT_TIMESTAMP and LOCALTIMESTAMP, both of which would suit our needs (since we're dropping the time zone when displaying or saving the next last-value). I've decided to go with CURRENT_TIMESTAMP only because we're using the function with the same name for other SQL DBs. > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SQOOP-3288) Incremental import's upper bound ignores session time zone in Oracle
[ https://issues.apache.org/jira/browse/SQOOP-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370164#comment-16370164 ] Attila Szabo commented on SQOOP-3288: - [~dvoros], Please link the review board as well! Next time please do not forgot to fill out the fix version (it's incredible useful when someone grooming these things for a release !!! ) Have you considered the usage of SYSTIMESTAMP? AFAIK it's a timezone aware timestamp. Cheers, [~maugli] > Incremental import's upper bound ignores session time zone in Oracle > > > Key: SQOOP-3288 > URL: https://issues.apache.org/jira/browse/SQOOP-3288 > Project: Sqoop > Issue Type: Bug > Components: connectors/oracle >Affects Versions: 1.4.7 >Reporter: Daniel Voros >Assignee: Daniel Voros >Priority: Major > Fix For: 1.5.0 > > Attachments: SQOOP-3288.1.patch > > > At the moment we're using [{{SELECT SYSDATE FROM > dual}}|https://github.com/apache/sqoop/blob/3153c3610da7e5db388bfb14f3681d308e9e89c6/src/java/org/apache/sqoop/manager/OracleManager.java#L652] > when getting current time from Oracle. > SYSDATE returns the underlying operating system's current time, while > CURRENT_TIMESTAMP uses the session time zone. This could lead to problems > during incremental imports *when Oracle's time zone is different from the OS*. > Consider the following scenario when Oracle is configured to {{+0:00}}, while > the OS is {{+5:00}}: > ||Oracle time||OS time||Event|| > |2:00|7:00|{{sqoop import --last-value 1:00 ...}} => imports {{[1:00, 7:00)}}| > |2:30|7:30|{{update ... set last_updated = current_timestamp ...}} => set to > {{2:30}} *Won't be imported!*| > |3:00|8:00|{{sqoop import --last-value 7:00 ...}} => imports {{[7:00, 8:00)}}| > This way records updated within 5 hours after the last sqoop import won't get > imported. > Please note, that the example above assumes, that the user/administrator > who's updating the Oracle table will use the current session time of Oracle > when setting the "last updated" column of the table. > I think the solution is to use CURRENT_TIMESTAMP instead of SYSDATE. Other > connection managers, like MySQL or PostgreSQL are using that as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)