Perl DateTime error with Oracle 10g #316

johannwilfling · 2016-09-22T12:59:41Z

Error

$ sqitch status -t sqitch@database
On database sqitch@database
The following parameter was passed in the call to DateTime::new but was not listed in the validation options: 06
 at /usr/lib/x86_64-linux-gnu/perl5/5.22/DateTime.pm line 198.
    DateTime::new(undef, "year", 2016, "month", 09, "day", "hour", 12, "minute", ...) called at /usr/share/perl5/App/Sqitch/Role/DBIEngine.pm line 27

Steps to reproduce

After hitting the same error with self compiled Sqitch and Perl packages with CentOS, I've used the Debian packages from "unstable" (sid):

apt-get install sqitch libdbd-oracle-perl

Versions

(Oracle Version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production)

$ sqitch --version
sqitch (App::Sqitch) 0.9995

$ dpkg -l | grep perl | grep date
ii  libdata-optlist-perl               0.110-1                     all          module to parse and validate simple name/value option pairs
ii  libdatetime-locale-perl            1:1.05-1                    all          Perl extension providing localization support for DateTime
ii  libdatetime-perl                   2:1.36-1                    amd64        module for manipulating dates, times and timestamps
ii  libdatetime-timezone-perl          1:2.01-1+2016f              all          framework exposing the Olson time zone database to Perl
ii  libparams-validate-perl            1.24-1                      amd64        Perl module to validate parameters to Perl method/function calls
ii  libtimedate-perl                   2.3000-2                    all          collection of modules to manipulate date/time information

Sqitch

$ sqitch init myschema --engine oracle
Created sqitch.conf
Created sqitch.plan
Created deploy/
Created revert/
Created verify/

$ sqitch target add sqitch@database db:oracle://sqitch:@/DATABASE
$ sqitch status -t sqitch@database
# On database sqitch@database
No changes deployed

$ sqitch add initial_schema -n 'Existing schema from Oracle database'
Created deploy/initial_schema.sql
Created revert/initial_schema.sql
Created verify/initial_schema.sql
Added "initial_schema" to sqitch.plan

$ sqitch deploy --log-only --to initial_schema -t sqitch@database
Adding registry tables to sqitch@database
Deploying changes through initial_schema to sqitch@database
  + initial_schema .. ok

$ sqitch status -t sqitch@database
# On database sqitch@database
The following parameter was passed in the call to DateTime::new but was not listed in the validation options: 06
 at /usr/lib/x86_64-linux-gnu/perl5/5.22/DateTime.pm line 198.
    DateTime::new(undef, "year", 2016, "month", 09, "day", "hour", 12, "minute", ...) called at /usr/share/perl5/App/Sqitch/Role/DBIEngine.pm line 27
    App::Sqitch::Role::DBIEngine::_dt("year:2016:month:09:day:hour:12:minute:44:second:06:time_zone") called at /usr/share/perl5/App/Sqitch/Role/DBIEngine.pm line 159
    App::Sqitch::Role::DBIEngine::current_state(App::Sqitch::Engine::oracle=HASH(0x28e47b8), "myschema") called at /usr/share/perl5/App/Sqitch/Command/status.pm line 119
    App::Sqitch::Command::status::try {...} () called at /usr/share/perl5/Try/Tiny.pm line 101
    eval {...} called at /usr/share/perl5/Try/Tiny.pm line 94
    Try::Tiny::try(CODE(0x24f0168), Try::Tiny::Catch=REF(0x2232a80)) called at /usr/share/perl5/App/Sqitch/Command/status.pm line 130
    App::Sqitch::Command::status::execute(App::Sqitch::Command::status=HASH(0x2310138)) called at /usr/share/perl5/App/Sqitch.pm line 191
    App::Sqitch::try {...} () called at /usr/share/perl5/Try/Tiny.pm line 101
    eval {...} called at /usr/share/perl5/Try/Tiny.pm line 94
    Try::Tiny::try(CODE(0xc32f30), Try::Tiny::Catch=REF(0x1e9b6c8)) called at /usr/share/perl5/App/Sqitch.pm line 211
    App::Sqitch::go("App::Sqitch") called at /usr/bin/sqitch line 14

The text was updated successfully, but these errors were encountered:

johannwilfling · 2016-09-23T11:39:36Z

Validated with Debian Docker Image (FROM perl:latest) and installed Sqitch and DBD::Oracle with

cpan App::Sqitch
cpan DBD::Oracle

Error is a following:

$ sqitch status sqitch@database
# On database sqitch@database
Validation failed for type named DayOfMonth declared in package DateTime::Types (/usr/local/lib/perl5/site_perl/5.24.0/x86_64-linux/DateTime/Types.pm) at line 29 in sub named (eval) with value "hour"

Trace begun at /usr/local/lib/perl5/site_perl/5.24.0/Specio/Exception.pm line 43
Specio::Exception::BUILD('Specio::Exception=HASH(0x3abb5d0)', 'HASH(0x3e66f38)') called at Specio::Exception->new line 57
Eval::Closure::Sandbox_17::__ANON__('Specio::Exception', 'message', 'Validation failed for type named DayOfMonth declared in package DateTime::Types (/usr/local/lib/perl5/site_perl/5.24.0/x86_64-linux/DateTime/Types.pm) at line 29 in sub named (eval) with value "hour"', 'type', 'Specio::Constraint::Simple=HASH(0x3c28dc0)', 'value', 'hour') called at /usr/local/lib/perl5/site_perl/5.24.0/Specio/Exception.pm line 62
Specio::Exception::throw('Specio::Exception', 'message', 'Validation failed for type named DayOfMonth declared in package DateTime::Types (/usr/local/lib/perl5/site_perl/5.24.0/x86_64-linux/DateTime/Types.pm) at line 29 in sub named (eval) with value "hour"', 'type', 'Specio::Constraint::Simple=HASH(0x3c28dc0)', 'value', 'hour') called at (eval 501) line 88
DateTime::_check_new_params('year', 2016, 'month', 09, 'day', 'hour', 11, 'minute', 33, 'second', 56, 'time_zone') called at /usr/local/lib/perl5/site_perl/5.24.0/x86_64-linux/DateTime.pm line 160
DateTime::new('App::Sqitch::DateTime', 'year', 2016, 'month', 09, 'day', 'hour', 11, 'minute', 33, 'second', 56, 'time_zone') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch/Role/DBIEngine.pm line 27
App::Sqitch::Role::DBIEngine::_dt('year:2016:month:09:day:hour:11:minute:33:second:56:time_zone') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch/Role/DBIEngine.pm line 159
App::Sqitch::Role::DBIEngine::current_state('App::Sqitch::Engine::oracle=HASH(0x3b05aa8)', 'wia') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch/Command/status.pm line 119
App::Sqitch::Command::status::try {...}  at /usr/local/lib/perl5/site_perl/5.24.0/Try/Tiny.pm line 101
eval {...} at /usr/local/lib/perl5/site_perl/5.24.0/Try/Tiny.pm line 94
Try::Tiny::try('CODE(0x378f840)', 'Try::Tiny::Catch=REF(0x35329f0)') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch/Command/status.pm line 130
App::Sqitch::Command::status::execute('App::Sqitch::Command::status=HASH(0x35f9660)', 'sqitch@standby') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch.pm line 191
App::Sqitch::try {...}  at /usr/local/lib/perl5/site_perl/5.24.0/Try/Tiny.pm line 101
eval {...} at /usr/local/lib/perl5/site_perl/5.24.0/Try/Tiny.pm line 94
Try::Tiny::try('CODE(0x31716f0)', 'Try::Tiny::Catch=REF(0x31d9160)') called at /usr/local/lib/perl5/site_perl/5.24.0/App/Sqitch.pm line 211
App::Sqitch::go('App::Sqitch') called at /usr/local/bin/sqitch line 14

theory · 2016-09-26T20:30:03Z

What's the output of this query on your install of Oracle?

SELECT to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"') FROM DUAL;

theory · 2016-09-26T20:34:13Z

It should be something like

year:2016:month:09:day:22:hour:11:minute:33:second:56:time_zone:UTC

But it looks like the string you get from the database does not include the day (22 in this example) or the time zone (UTC in this example). Which is just weird. Isn't DD the proper format for the day of the month? And what happened to "UTC", which should be literal?

johannwilfling · 2016-09-27T11:36:17Z

I've tried it with 'sqlplus' at the database server itself, Oracle Instantclient (12.1.0.2.0-1), and Oracle SQL-Developer (4.x), but the output is as following:

SQL> SELECT to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"') FROM DUAL;

TO_CHAR(CURRENT_TIMESTAMPATTIMEZONE'UTC','"YEAR":YYYY:"MONTH":MM:"DAY":DD')||TO_
--------------------------------------------------------------------------------
year:2016:month:09:day:hour:11:minute:25:second:59:time_zone

It seems to be a weird behaviour of the variable binding / substitution. I'm using 'systimestamp' for simplification:

SQL> select to_char(systimestamp) from dual;

TO_CHAR(SYSTIMESTAMP)
--------------------------------------------------------------------------------
27-SEP-16 08.18.43.835173 AM +02:00

SQL> select to_char(systimestamp, 'YYYY') from dual;

TO_CHAR(SYST
------------
2016

SQL> select to_char(systimestamp, '"In the year: "YYYY') from dual;

TO_CHAR(SYSTIMESTAMP,'"INTHEYEAR:"YYYY')
---------------------------------------------------
In the year: 2016

SQL> select to_char(systimestamp, '"day:"DD') from dual;

TO_CHAR(SYSTIMESTA
------------------
day:27

If there are other literals within quotes, the last characters get truncated:

SQL> select to_char(systimestamp, '"day:"DD"hello"') from dual;

TO_CHAR(SYSTIMESTAMP,'"DAY:"DD"HE
---------------------------------
day:27hel

The only workaround is to concat the string, which could be in fact quite combersome:

SQL> select to_char(systimestamp, '"day:"DD') || ':hello' from dual;

TO_CHAR(SYSTIMESTAMP,'"DAY:"DD')||':
------------------------------------
day:27:hello

theory · 2016-09-27T17:49:37Z

Good grief Oracle. Okay, please try this:

SELECT to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"month":MM')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"day":DD')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"minute":MI')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"second":SS')
    || :"time_zone":"UTC"';

johannwilfling · 2016-09-28T05:46:05Z

The correct statement would be:

SELECT to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"month":MM')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"day":DD')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"minute":MI')
    || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"second":SS')
    || ':time_zone:UTC' from dual;

TO_CHAR(CURRENT_TIMESTAMPATTIMEZONE'UTC','"YEAR":YYYY')||TO_CHAR(CURRENT_TIMESTA
--------------------------------------------------------------------------------
year:2016:month:09:day:28:hour:05:minute:44:second:44:time_zone:UTC

Changes to your previous statement:

Removed double colon after YYYY
Added missing single quote in the last line
Removed double quotes from time_zone and UTC (are already literals)
Added "from dual"

theory · 2016-09-28T16:19:46Z

Okay, well, this seems kind of stupid. The reason there were two calls to to_char() in the first place were to avoid this problem. But I wonder if there's some sort of configuration knob you can turn in Oracle tell it to allocate a bigger buffer for to_char() to use and return. That would be the more efficient solution.

johannwilfling · 2016-09-29T14:53:08Z

Seems to be an Oracle 10g issue. I've quick test it with an Oracle 11g XE docker image:

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

SQL>
SQL>
SQL> SELECT to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', 'fm"year":YYYY:"month":MM:"day":DD') || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"') FROM DUAL;

TO_CHAR(CURRENT_TIMESTAMPATTIMEZONE'UTC','FM"YEAR":YYYY:"MONTH":MM:
-------------------------------------------------------------------
year:2016:month:9:day:27:hour:14:minute:12:second:56:time_zone:UTC

I'm gonna fork and maintain a custom Sqitch repository, until we can get rid of Oracle 10g ..

theory · 2016-09-29T17:26:40Z

This seems crazy. I posted a StackOverflow question to see if someone knows of a configuration variable to set or something.

See issue sqitchers#316

theory · 2016-11-02T21:38:47Z

Hey @johannwilfling, can you take look at this SO answer? The issue might be with SQL*Plus…

nmaqsudov · 2016-11-08T22:03:37Z

It could deal with NLS. I posted the answer to the same SO question. Enough buffer could be allocated independently from any other conditions or parameters if you explicitly typecast the expression "as varchar2(N char)"

cast(to_char(systimestamp, '"day:"DD"hello"') as varchar2(11 char)

theory · 2016-11-10T21:15:39Z

Hrm, I thought maybe I could just have one call to to_char(), so I tried this:

CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD:"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"') AS VARCHAR2(92 char))

But then in a DBI call I got this error:

ORA-01801: date format is too long for internal buffer (DBD ERROR: OCIStmtFetch)

Will try keeping the date and time separate again. :-(

theory · 2016-11-10T21:32:07Z

Okay, this seems to work:

CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(92 char))

I'll commit that; would be great if you could try it out, @johannwilfling.

Ref #316.

johannwilfling · 2016-11-22T10:39:19Z

Sorry for responding so late due to sickness / vacation.

But unfortunately the cast to varchar didn't work either:

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Nov 22 11:29:08 2016

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') || to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(92 char)) from dual;

CAST(TO_CHAR(CURRENT_TIMESTAMPATTIMEZONE'UTC','"YEAR":YYYY:"MONTH":MM:"DAY":DD')
--------------------------------------------------------------------------------
year:2016:month:11:day:hour:10:minute:29:second:16:time_zone

SQL>

I do really think that this is a bug of the 10.2.0.1.0 release (SQLDeveloper, Toad didn't work either).
I really appreciate your efforts, but I'll maintain a fork until we can get rid of Oracle 10.2.0.1.0 .. ;-)

theory · 2016-11-22T16:47:35Z

Hrm. Maybe try this:

select CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') AS VARCHAR2(92 char)) || CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(92 char)) from dual;

johannwilfling · 2016-11-23T06:41:40Z

Sorry .. :-(

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Nov 23 07:39:10 2016

Copyright (c) 1982, 2005, Oracle.  All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> select CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') AS VARCHAR2(92 char)) || CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(92 char)) from dual;

CAST(TO_CHAR(CURRENT_TIMESTAMPATTIMEZONE'UTC','"YEAR":YYYY:"MONTH":MM:"DAY":DD')
--------------------------------------------------------------------------------
year:2016:month:11:day:hour:06:minute:39:second:17:time_zone

SQL>

theory · 2018-09-24T15:06:17Z

Hi, sorry for the radio silence. Is this still an issue, @johannwilfling?

nmaqsudov · 2018-09-24T15:58:57Z

It looks like your Oracle allocates a character buffer for wrong length semantica. You are using AS VARCHAR2(92 **char**), but on allocation if thinks that the length semantics id byte. Look, 92/4 = 23; allocated character buffer is for 23 chars only.
year:2016:month:11:day: is exactly 23 chars.
CAST predicate cuts the result and makes it 23 chars.
Expected length of the value like year:2018:month:09:day:24 is 25 chars or 100 bytes.
Try to allocate more space and specify it in bytes*4:

SQL> select CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') AS VARCHAR2(100 byte)) || CAST(to_char(CURRENT_TIMESTAMP AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(168 byte)) from dual;

P.S.
168 is valid if timezone name length is 3 chars.

theory · 2018-09-24T22:33:26Z

That sounds like the likely culprit, @nmaqsudov — thanks! @johannwilfling can you let me know if that version fo the query works for you? Hoping to release v0.9998 this week.

johannwilfling · 2019-01-08T12:59:08Z

Sorry for the late response .. unfortunately building with Perl 5.28.0 and Sqitch v.0.9998 results with the following error:

sqitch status -t sqitch@standby
# On database sqitch@standby
Validation failed for type named DayOfMonth declared in package DateTime::Types (/usr/local/lib/perl5/site_perl/5.28.0/x86_64-linux-gnu/DateTime/Types.pm) at line 29 in sub named (eval) with value "hour"

Trace begun at Specio::Exception->new line 57
Specio::Exception::throw('Specio::Exception', 'message', 'Validation failed for type named DayOfMonth declared in package DateTime::Types (/usr/local/lib/perl5/site_perl/5.28.0/x86_64-linux-gnu/DateTime/Types.pm) at line 29 in sub named (eval) with value "hour"', 'type', 'Specio::Constraint::Simple=HASH(0x5646f85a89e8)', 'value', 'hour') called at (eval 511) line 91
DateTime::_check_new_params('year', 2019, 'month', 01, 'day', 'hour', 12, 'minute', 48, 'second', 18, 'time_zone') called at /usr/local/lib/perl5/site_perl/5.28.0/x86_64-linux-gnu/DateTime.pm line 176
DateTime::new('App::Sqitch::DateTime', 'year', 2019, 'month', 01, 'day', 'hour', 12, 'minute', 48, 'second', 18, 'time_zone') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Role/DBIEngine.pm line 28
App::Sqitch::Role::DBIEngine::_dt('year:2019:month:01:day:hour:12:minute:48:second:18:time_zone') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Role/DBIEngine.pm line 160
App::Sqitch::Role::DBIEngine::current_state('App::Sqitch::Engine::oracle=HASH(0x5646f7e71348)', 'aau') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Command/status.pm line 120
App::Sqitch::Command::status::try {...}  at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 100
eval {...} at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 93
Try::Tiny::try('CODE(0x5646f7a85758)', 'Try::Tiny::Catch=REF(0x5646f781b858)') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Command/status.pm line 131
App::Sqitch::Command::status::execute(undef) called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch.pm line 214
App::Sqitch::try {...}  at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 100
eval {...} at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 93
Try::Tiny::try('CODE(0x5646f74b1068)', 'Try::Tiny::Catch=REF(0x5646f7509bf0)') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch.pm line 234
App::Sqitch::go('App::Sqitch') called at /usr/local/bin/sqitch line 14

theory · 2019-01-09T02:54:08Z

DateTime::new('App::Sqitch::DateTime', 'year', 2019, 'month', 01, 'day', 'hour', 12, 'minute', 48, 'second', 18, 'time_zone') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Role/DBIEngine.pm line 28

That's pretty fucked up. Jebus Oracle. Just out of curiosity, does this patch make a difference?

--- a/lib/App/Sqitch/Engine/oracle.pm
+++ b/lib/App/Sqitch/Engine/oracle.pm
@@ -139,7 +139,7 @@ sub _log_conflicts_param {
 }
 
 sub _ts2char_format {
-    q{CAST(to_char(%1$s AT TIME ZONE 'UTC', '"year":YYYY:"month":MM:"day":DD') AS VARCHAR2(100 byte)) || CAST(to_char(%1$s AT TIME ZONE 'UTC', ':"hour":HH24:"minute":MI:"second":SS:"time_zone":"UTC"')  AS VARCHAR2(168 byte))}
+    q{CAST(to_char(%1$s AT TIME ZONE 'UTC', '"year:"YYYY":month:"MM":day:"DD') AS VARCHAR2(100 byte)) || CAST(to_char(%1$s AT TIME ZONE 'UTC', '":hour:"HH24":minute:"MI":second:"SS":time_zone:UTC"')  AS VARCHAR2(168 byte))}
 }
 
 sub _ts_default { 'current_timestamp' }

johannwilfling · 2019-01-09T08:18:27Z

New day - new error .. 😉

I've applied the above patch onto tag version v0.9998 and got the following error:

/usr/src/sqitch# sqitch status -t sqitch@standby
# On database sqitch@standby
Found extra parameters passed to _check_new_params: [12, 18, 48, da]

Trace begun at (eval 589) line 301
DateTime::_check_new_params('year', 2019, 'month', 01, 'da', 'hour', 12, 'minute', 48, 'second', 18, 'time_zo') called at /usr/local/lib/perl5/site_perl/5.28.0/x86_64-linux-gnu/DateTime.pm line 176
DateTime::new('App::Sqitch::DateTime', 'year', 2019, 'month', 01, 'da', 'hour', 12, 'minute', 48, 'second', 18, 'time_zo') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Role/DBIEngine.pm line 28
App::Sqitch::Role::DBIEngine::_dt('year:2019:month:01:da:hour:12:minute:48:second:18:time_zo') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Role/DBIEngine.pm line 160
App::Sqitch::Role::DBIEngine::current_state('App::Sqitch::Engine::oracle=HASH(0x55915b90bd10)', 'aau') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Command/status.pm line 120
App::Sqitch::Command::status::try {...}  at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 100
eval {...} at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 93
Try::Tiny::try('CODE(0x55915b694750)', 'Try::Tiny::Catch=REF(0x55915b280b90)') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch/Command/status.pm line 131
App::Sqitch::Command::status::execute(undef) called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch.pm line 214
App::Sqitch::try {...}  at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 100
eval {...} at /usr/local/lib/perl5/site_perl/5.28.0/Try/Tiny.pm line 93
Try::Tiny::try('CODE(0x55915b25f968)', 'Try::Tiny::Catch=REF(0x55915af18b68)') called at /usr/local/lib/perl5/site_perl/5.28.0/App/Sqitch.pm line 234
App::Sqitch::go('App::Sqitch') called at /usr/local/bin/sqitch line 14

As we have a very old version of OracleDB, I want to mention that we can live with my previously working patch and stick with Sqitch version v0.9995 ..

theory · 2019-01-10T14:52:14Z

You mean this one?

johannwilfling · 2019-01-11T08:11:52Z

Yeah .. until now, we are working with this patch:
johannwilfling@7bbbc76

Seems to be ugly, but it works ..

theory · 2019-01-11T18:20:51Z

That workaround just…offends me. :-( I've pulled in your fix in 38d13cf and it will be in the v0.9999 release. Thanks for bearing with me.

johannwilfling added a commit to johannwilfling/sqitch that referenced this issue Oct 5, 2016

Fixes an Oracle database 10.2.0.1.0 bug

7bbbc76

See issue sqitchers#316

theory added the engine label Oct 17, 2016

theory added this to the v1.0.0 milestone Oct 17, 2016

theory added a commit that referenced this issue Nov 10, 2016

Try to fix Oracle date truncation bug.

8a04700

Ref #316.

theory closed this as completed in e0d4ccb Sep 24, 2018

theory reopened this Jan 9, 2019

theory closed this as completed in 38d13cf Jan 11, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Perl DateTime error with Oracle 10g #316

Perl DateTime error with Oracle 10g #316

johannwilfling commented Sep 22, 2016

johannwilfling commented Sep 23, 2016

theory commented Sep 26, 2016

theory commented Sep 26, 2016

johannwilfling commented Sep 27, 2016

theory commented Sep 27, 2016 •

edited

johannwilfling commented Sep 28, 2016

theory commented Sep 28, 2016

johannwilfling commented Sep 29, 2016

theory commented Sep 29, 2016

theory commented Nov 2, 2016

nmaqsudov commented Nov 8, 2016

theory commented Nov 10, 2016

theory commented Nov 10, 2016 •

edited

johannwilfling commented Nov 22, 2016

theory commented Nov 22, 2016

johannwilfling commented Nov 23, 2016

theory commented Sep 24, 2018

nmaqsudov commented Sep 24, 2018

theory commented Sep 24, 2018

johannwilfling commented Jan 8, 2019

theory commented Jan 9, 2019

johannwilfling commented Jan 9, 2019

theory commented Jan 10, 2019

johannwilfling commented Jan 11, 2019

theory commented Jan 11, 2019

Perl DateTime error with Oracle 10g #316

Perl DateTime error with Oracle 10g #316

Comments

johannwilfling commented Sep 22, 2016

Error

Steps to reproduce

Versions

Sqitch

johannwilfling commented Sep 23, 2016

theory commented Sep 26, 2016

theory commented Sep 26, 2016

johannwilfling commented Sep 27, 2016

theory commented Sep 27, 2016 • edited

johannwilfling commented Sep 28, 2016

theory commented Sep 28, 2016

johannwilfling commented Sep 29, 2016

theory commented Sep 29, 2016

theory commented Nov 2, 2016

nmaqsudov commented Nov 8, 2016

theory commented Nov 10, 2016

theory commented Nov 10, 2016 • edited

johannwilfling commented Nov 22, 2016

theory commented Nov 22, 2016

johannwilfling commented Nov 23, 2016

theory commented Sep 24, 2018

nmaqsudov commented Sep 24, 2018

theory commented Sep 24, 2018

johannwilfling commented Jan 8, 2019

theory commented Jan 9, 2019

johannwilfling commented Jan 9, 2019

theory commented Jan 10, 2019

johannwilfling commented Jan 11, 2019

theory commented Jan 11, 2019

theory commented Sep 27, 2016 •

edited

theory commented Nov 10, 2016 •

edited