[CORALCOOL-540] unsigned long long numbers are changed to signed in Bulk
insertion (ORACLE) Created: 21/May/08 Updated: 30/May/08 Resolved: 29/May/08
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
CORAL and COOL
CORAL
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Zhen Xie
Fixed
None
Not Specified
External issue
ID:
External issue
URL:
bugs36835
CORAL_1_9_7
Priority:
Assignee:
Votes:
Blocker
Alexander Kalkhof
0
Not Specified
Not Specified
http://savannah.cern.ch/bugs/?36835
Description
Hi Giacomo,
I have the following problem:
this data model
struct IOV
{ std::vector<std::pair<unsigned long long,std::string>> content; }
;
seems cannot handle large unsigned long long numbers. When storing, POOL turns the number
from unsigned to signed. Even when the schema is correctly created as oracle type
NUMBER(20).
If I log in oracle with sqlplus and insert 8446744073709551615 into table a( b NUMBER(20);
the column is correctly created as this number;
if I use pool(see example):
datasvc->transaction().start(pool::ITransaction::UPDATE);
cond::IOV* me=new cond::IOV(1,1);
pool::Ref< cond::IOV > simple(datasvc,me);
me->add(18446744073709551615ULL,"a&quot;);
simple.markWrite(place);
datasvc->transaction().commit();
The responsible column is turned into -1.
Could you please see if you can reproduce the problem and identify where the problem comes
from?
It seems coral type mapping is correct: unsigned long long is mapped to NUMBER(20).
thanks,
Zhen
Comments
Comment by Zhen Xie [ 22/May/08 ]
this is to confirm that CORAL works fine with unsigned long long.
So the problem comes either from relational storage service or reflex gives wrong information...
zhen
Comment by Witold Pokorski [ 26/May/08 ]
Hi Zhen,
I can reproduce your problem. No idea where it comes from, yet...
Cheers,
Witek
Comment by Giacomo Govi [ 27/May/08 ]
Ok, I can also reproduce the problem, by strictly using Zhen code:
me->add(18446744073709551615ULL,"a&quot;);
The added number has a "1" in front of the maximum storable unsigned long long (which is
8446744073709551615), and therefore is normal that one gets back -1.
I will close the bug.
Cheers
Giacomo
Comment by Zhen Xie [ 27/May/08 ]
Am I out of my mind??
2**64-1=18446744073709551615L
Where it says the max unsigned long long is 8446744073709551615?
Zhen
Comment by Giacomo Govi [ 27/May/08 ]
Hi,
using the simple code below I have reproduced the problem in a CORAL stand-alone
application. It pops up using the bulk intertion (which is adopted by POOL to store array data,
as from the Zhen use case).
One can see in the table that TableDataEditor::insert produces correct insertion in the table,
while BulkInserter does not.
I forward the case to the CORAL team.
Cheers
Giacomo
coral::ConnectionService connServ;
coral::ISessionProxy* session = connServ.connect(m_connectionString );
coral::ISchema& schema = session->nominalSchema();
session->transaction().start();
coral::AttributeList data;
data.extend<unsigned long long>("MY_ULONGLONG&quot;);
data["MY_ULONGLONG"].data<unsigned long long>()=18446744073709551000ULL;
coral::IBulkOperation* bulkInserter =
schema.tableHandle("IOV_CONTENT&quot;).dataEditor().bulkInsert(data,10);
bulkInserter->processNextIteration();
bulkInserter->flush();
schema.tableHandle("IOV_CONTENT&quot;).dataEditor().insertRow( data );
session->transaction().commit();
Comment by Zhen Xie [ 29/May/08 ]
Hi, I've spotted one place that this conversion happened. It's in
coral/OracleAccess/src/BulkOperation.cpp
else if ( attributeType == typeid(unsigned long long) )
{ m_dataCache.push_back( new coral::OracleAccess:\:PolymorphicTVector<long long>(
m_rowsInCache, m_properties.errorHandle() ) ); }
Could you please commit/tag the fix?
thanks,
Zhen
Comment by Alexander Kalkhof [ 29/May/08 ]
Changes are made and tagged as CORAL-preview
cheers
alex
Comment by Zhen Xie [ 29/May/08 ]
thanks. But could you please make the fix also on top of current production release of coral
instead of seal-less coral?
CMS does not and will not use coral-preview for some time. This is a blocking bug for us and
should be released as patch to the production release a.s.a.p.
Comment by Alexander Kalkhof [ 30/May/08 ]
I created a new branch for the changes : CORAL_1_9_x
I hope that will work for you
cheers alex
Comment by Alexander Kalkhof [ 30/May/08 ]
the branch name is CORAL_1_9_X
and the tag CORAL_1_9-patches
Generated at Wed Feb 10 07:03:18 CET 2016 using JIRA 6.4.9#64024sha1:1f1084e06c9893c77549621edbccfecfaa68be5d.