Hi,
I think there is a problem with code in cvs in CopyDecimal.
This CopySQLData instance is now (in cvs) the default for numeric types, but when used with sql data it fails to convert numeric sql types to clover types...
Is this a known problem or should I dig a bit more ?
(problem occurs in DBOutputTable at line 408 :
inRecord = readRecord(READ_FROM_PORT, inRecord);
)
Thanks,
Franck
I think there is a problem with code in cvs in CopyDecimal.
This CopySQLData instance is now (in cvs) the default for numeric types, but when used with sql data it fails to convert numeric sql types to clover types...
Is this a known problem or should I dig a bit more ?
(problem occurs in DBOutputTable at line 408 :
inRecord = readRecord(READ_FROM_PORT, inRecord);
)
Thanks,
Franck
-
Well, I now realise that cvs code for CloverETL is moving fast, but is not always in a coherent state.
So after a fresh update, the problem has gone, but another one is occuring, a null pointer exception.
My question now is more like :
- do you care about bug reports on cvs, or is cvs your daily workspace, so bugs come and go out of it as quickly as you code ?
For the setAutoCommit stuff needed for Postgresql to work on big tables, I just "backpoted" it to 1.1.7 (well, cut and paste the try catch block :-)
Thanks,
Franck -
Ok, so here is my bug report.
I have that simple graph (DB_Input_Table --> DB_Output_Table) and I get this exception :
INFO [WatchDog] - [WatchDog] Sucessfully started all nodes in phase!
DEBUG [DB_OUTPUT_TABLE0] - insert into obbud values(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
WARN [DB_OUTPUT_TABLE0] - No metadata obtained for table: "obbud", using workaround ...
INFO [WatchDog] - [WatchDog] !!! Fatal Error !!! - graph execution is aborting
FATAL [WatchDog] - Node DB_INPUT_TABLE0 finished with fatal error: java.lang.RuntimeException : java.lang.NullPointerException:null
[snip]
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at org.jetel.graph.DirectEdge.fillReadBuffer(Unknown Source)
at org.jetel.graph.DirectEdge.readRecord(Unknown Source)
at org.jetel.graph.Edge.readRecord(Unknown Source)
at org.jetel.graph.Node.readRecord(Unknown Source)
The very same graph works like a charm in 1.1.7 (with setAutoCommit(false) trick), and it even works on a very similar one, just working on another table.
I don't really know were to look for.
Any more info needed ?
Franck -
Hi Martin,
sure, nothing special I think... Here it is :
temporaire=# \d obbud
Table «public.obbud»
Colonne | Type | Modificateurs
----------+------------------------+---------------
etsobbud | character varying(6) | not null
butobbud | character varying(2) | not null
moiobbud | character varying(8) | not null
tafobbud | character varying(2) | not null
cgrobbud | character varying(80) | not null
posobbud | character varying(10) | not null
cptobbud | character varying(10) |
mtdobbud | numeric(22,0) | not null
mtcobbud | numeric(22,0) | not null
unoobbud | character varying(6) |
quoobbud | numeric(22,0) |
etaobbud | character varying(1) | not null
typobbud | character varying(2) |
natobbud | character varying(2) |
genobbud | character varying(2) |
rolobbud | character varying(1) |
infobbud | character varying(240) |
cgoobbud | character varying(80) |
pooobbud | character varying(10) |
ctoobbud | character varying(10) |
tycobbud | character varying(1) |
pctobbud | numeric(22,0) |
ucrobbud | character varying(30) | not null
dcrobbud | character varying(8) | not null
udmobbud | character varying(30) |
ddmobbud | character varying(8) |
tmsobbud | numeric(22,0) | not null
devobbud | character varying(6) |
ddvobbud | character varying(8) |
dvmobbud | character varying(2) |
vprobbud | numeric(22,0) |
mddobbud | numeric(22,0) |
mdcobbud | numeric(22,0) |
dvoobbud | character varying(6) |
drvobbud | character varying(8) |
drmobbud | character varying(2) |
vrrobbud | numeric(22,0) |
mrdobbud | numeric(22,0) |
mrcobbud | numeric(22,0) |
nuiobbud | numeric(22,0) | not null
Could this be caused by the request being too long ?
Franck -
Hello Franck !
Yes, we do care about bug reports on cvs !
As you correctly realized, cvs is changing quickly and the only way to get something guaranteed is to use TAGs which are assigned to each released version. The last TAG of stable release is 1.1.7.
Since the code is worked on by several developers, it is hard to keep only correct pieces. It happens, that somebody checks in new version which is two days later replaced by some fix.
David.
Please sign in to leave a comment.
Comments 7