[SPAGOBI-2013] Cannot create LOV from DataSet Created: 13/Jan/15  Updated: 22/Sep/15

Status: Open
Project: SpagoBI
Component/s: SERVER/Database
Affects Version/s: 5.1.0 RC
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Hristijan Petreski Assignee: Marco Cortella
Resolution: Unresolved Votes: 2
Labels: dataset
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Win 7 x64, Java 7, Tomcat 7

Issue Links:
Duplicate
duplicates SPAGOBI-2198 Dataset as a LOV type doesn't work an... Open
Bug type: New bug

 Description   
I have defined Impala (CDH 5.2) as Data Source. I have created Dataset to load some values. The preview works fine. However when I go to use this Dataset to create LOV I always get error: "... contact administrator" and the LOV is not created.
Doing some reverse engineering I saw this part of code in SpagoBIDAO (it.eng.spagobi.behaviouralmodel.lov.bo.DatasetDetail):

public void loadFromXML(String dataDefinition) throws SourceBeanException {
logger.debug("IN");
dataDefinition.trim();
if(dataDefinition.indexOf("<ID>")!=-1) {
int startInd = dataDefinition.indexOf("<ID>");
int endId = dataDefinition.indexOf("</ID>");
String dataset = dataDefinition.substring(startInd + 6, endId);
dataset =dataset.trim();
if(!dataset.startsWith("<![CDATA[")) {
dataset = "<![CDATA[" + dataset + "]]>";
dataDefinition = dataDefinition.substring(0, startInd + 6) + dataset + dataDefinition.substring(endId);
}
}
...

The LOV cannot get created because I get exception "out of bounds". If you see carefully and as I understand the creator wants to extract the id from <ID> id </ID> and put it inside CDATA, however using the beginning of the <ID> + 6 and then using the beginning of </ID> this will throw exception since the start is bigger than the end. As a solution that I tested and it works (at least for now) is to replace the "6" with 4 (the length of <ID>).

 Comments   
Comment by Marco Cortella [ 22/Sep/15 ]
It seems that the problem is the same.
Generated at Tue Aug 04 13:43:34 CEST 2020 using JIRA 7.2.2#72004-sha1:9d5132893cc8c728a3601a9034a1f8547ef5c7be.