Author Topic: Update/duplicate hit with duplicate display values in fixed values mapping  (Read 2692 times)

TTP4RFGrL3Ki

  • Guest
Dear reader,

as far as I know it's allowed to assign the same display value to different database values. (fixed values in ODCriteria)

CMOD configuration:
Code: [Select]
  display value : database value
  "Invoice" : "invoice123"
  "Invoice" : "invoicd234"
  "Statement" : "statement"
ODCriteria.getFixedValues(): (only unique entries, as well as returned by ODCriteria.getDBFixedValuesMapping())
Code: [Select]
  "Invoice"
  "Statement"
When searching this is no problem since CMOD returns hits for all database values mapping to the same display value. (And the search expects to get display values)

However, when updating or duplicating a hit, database values are expected.
This leads to these questions:
  • 1. how do I get all possible database values (so far I solved this with ODServer.xmlParse() to get the application group configuration)
  • how do I get the database (fixed) value of some criteria for a certain hit?
(2.) is necessary to keep the old database value for some criteria if the user doesn't select a different one

Any ideas?

I have the impression that the concept of having the same display value for multiple database values is only half implemented (for search, but not for updating/duplicating hits).

Andreas

Alessandro Perucchi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1002
    • View Profile
Hello Andreas,

I might give you some hints but maybe not the solution to your problem...

So first, here is a way to display (without using xmlParse()) the field mappings:

Code: [Select]
ODFolder odf = ods.openFolder("folder");
ODCriteria folderACriteria = odf.getCriteria("field");
Hashtable<String, String> listFieldMapping = folderACriteria.getDBFixedValuesBaseMapping("ApplicationGroup");
for ( Entry<String, String> entry : listFieldMapping.entrySet()) {
System.out.println("Display Value:["+entry.getKey()+"] - DB Value:["+entry.getValue()+"]" );
}

That works ok, but in my case, I have the following data:

Code: [Select]
  display value : database value
  "0000" : "00"
  "0000" : "03"
  "0001" : "01"
  "0001" : "02"
  "0001" : "07"
  "0002" : "04"
  "0002" : "06"
  "0003" : "05"

and after running my code, I get the following output:

Code: [Select]
Display Value:[0003] - DB Value:[05]
Display Value:[0002] - DB Value:[04]
Display Value:[0001] - DB Value:[02]
Display Value:[0000] - DB Value:[00]

As you can see, I am missing a lot of information here...

So this is to say that the ODServer.xmlParse() is the correct way to go... in order to have ALL the values, and not only a "selection"...

One comment... I use "getDBFixedValuesBaseMapping()" instead of "getDBFixedValuesMapping()" because this is the way to get the "original" value, or the default value set initially in the mapping. The method "getDBFixedValuesMapping" will give you the "translated" version of the fields. So if you don't use the multilingual property of CMOD, then "getDBFixedValuesBaseMapping" == "getDBFixedValuesMapping"... otherwise it will be more like "getDBFixedValuesBaseMapping" != "getDBFixedValuesMapping".


Now your second question concerning, how to get the database value of a ODHit, then you need to call the method ODHit.getDisplayValue().
Unfortunately... in my example, you will get maybe "0001", and you will NEVER know if that was 01, 02 or 07...

The other method that I can give you is to add a new field in your folder. For example you have already the field called "Document Type", then add "Document Type (internal)" and select in the folder Field Information tab the "Internal" field in the Defaults section. You can put to "0" the Query, but you must have a number in the Histliste... because you must see the output!!! with the value "0" you won't be able to read the value.
With that "trick" then you can have the "display" value in the normal folder field hit, and the internal "database" value in the new technical folder field.

Here is my code:

Code: [Select]
System.out.println("field Value = [" + odh.getDisplayValue("field") + "]");
System.out.println("internal field Value = ["+odh.getDisplayValuesTable().get("field internal")+"]");


and here is the output:

Code: [Select]
field Value = [0001]
internal field Value = [01]
field Value = [0000]
internal field Value = [00]
field Value = [0001]
internal field Value = [02]
field Value = [0001]
internal field Value = [02]
field Value = [0001]
internal field Value = [07]
field Value = [0003]
internal field Value = [05]
...

So if you don't want to mess up with the user view of the folder, you can either create a technical folder just for your needs OR you can create a new view in the current folder for your technical needs (1 folder = many views - 1 for users, 1 for technical user, 1 for admin search, 1 for power users, etc...)
Of course the advantage of having several folders, is that you can have many folders according to your needs at one point in time... the disadvantage... you'll get a lot of "duplicate" folders to administer...
The advantage of having several views, is that you have only 1 folder to administer, but the disadvantage, is that your can only see the view that your permission gave you, and you cannot change it without changing permissions! And it might be confusing also to have too much views in 1 folder so not nice to administer!!! :-D

I hope that helps you a little bit.

Cheers,
« Last Edit: January 08, 2016, 08:56:04 AM by Alessandro Perucchi »
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML

TTP4RFGrL3Ki

  • Guest
Thanks a lot, Alessandro!

Seems that CMOD users are easily trapped here: everything's fine as long as you don't want to update/duplicate a hit.
We're still evaluating what will be the best solution. Probably there will some customer specific code be needed...

Would be great if a future version of ODWEK would allow to access also the database values and not only display values.

Andreas