Structs and data-caching.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

Okay, so I am trying to play with structs to get around some problems I have. We have a component with a complex function within it to calculate the best stocks to use to produce cut pieces. I want to be able to execute this procedure, but allow the user to revert to the previous 'stored' value if they determine they don't like the current one. I was using xmlsave, but this requires a lot of coding to ensure the DTD matches the component structure. So, having upgraded to 9.5, I thought of structs. However, I am unsure how to handle this properly. I tried, (where old_optimise is a modeled non-database xmlstream, ) variables struct v_struct endvariables Componenttostruct v_struct structtoxml old_optimise, v_struct with the plan of restoring the current position using xmltostruct v_struct, old_optimise clear structtocomponent v_struct But this crashes uniface on the structtoxml. I am trying to make the recovery 'recursive' in that the user can optimise, optimise, optimise, and then back out undoing each one at a time, until they save to the database. (which is why I am trying to save the data in a field in the model, so the next optimise backs up the backup. ) Without the 'recursion' I tried using a component variable. This seems to work, but all the fields and occurrences are set to validate by structtocomponent. Are there any worked examples of caching the contents of a component I am not finding in the help?

7 Comments

  1. Hi Iain, What I've done in the past is to create a svc consisting of a non-db entity - two fields, seqno and a variable length text field. Seqno = save by user (curocc from creocc -1) variable length field = old occurence value three operations - add / get / delete You could use putlistitems/occ, xmlsave or the new struct's and store to the svc. When you need to, either add, get previous (or specific version) or delete.... Of course, there's the option to create a valuelist with a seqno and simply navigate up/down the valuelist - somehow I think that's more work on Uniface's behalf than a svc with a dummy entity - I might be wrong but large amounts of text in a valuelist - I'm not comfortable with that... Regards, Knut


    Author: Knut (knut.dybendahl@gmail.com)
  2. It's the ease of getting a complex data structure packed up into one unit which draws me to structs. Valuelists and putlistocc are a pain to maintain if there are a reasonable number of entities (say 10) nested in complex relationships. XML is a pain to maintain if the fields in the component are changing, as maintaining a mapped DTD for the component is bloody hard work. Structs look like the way to go, but you can't store them in occurrences to allow for the recursion, and I don't understand how you can create an index for the structure to allow easy retrieval. Also, there really isn't any sane way for any of these data stores to maintain state at a field level, meaning that all field validation has to be turned off whilst unpacking the data back into the component. Componenttostruct appears to suffer from the fact that it backs up empty entities, and structtocomponent then restores them with the key field marked as modified, meaning that they all then fail validation... all in all, it's a really hard job to just put a component's data in storage and fetch it back....


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. valuelists - yep, agree. xml - I personally use "load component structure" in the dtd editor - very fast and easy to remove extra fields painted that doesn't belong to the xml stream. BUT - I can see a use for the componenttostruct(/one) here.... ;================== componenttostruct/one v_struct1, "orders.sales" creocc "dummy", -1 occno.dummy = $curocc("dummy") structtoxml xml_struct.dummy, v_struct1 now you have the struct in XML - and can build a history.... As for the validate errors, once loading the data back to the entities, maybe using the trigger to either remocc or reset occmod would solve the problem? Knut


    Author: Knut (knut.dybendahl@gmail.com)
  4. Except that uniface crashes on the structtoxml on the component I tried this on. Just plain crashes, kicks me out, gone, finished, no error messages just goodbye. So I have no chance of working out what it is that it doesn't like.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  5. Hi Iain, Which version 9.5 patch level do you use? I'm aware of a problem with the structToXml statement when the struct contains an empty leave of type Boolean. This usually can happen when you convert the data of a component to a struct (using componentToStruct) and the component in question features a Boolean field that is empty. The mentioned occurs problem when using the patch E113 (or higher) - in lower patch levels the problem did not occur since all data in a struct is of type String. And we currently plan to resolve this issue in the patch E118 (scheduled for July 19). Should the above issue be different from what you are experiencing then we are dealing with a new problem here. In any case, please open a support call for this issue and we can have better look at this matter. Hope this helps. Thanks, Daniel


    Author: diseli (daniel.iseli@uniface.com)
  6. Hi, I meet such situation. To avoid this, convert the component to struct at the height level entity: componenttostruct v_struct, "ENTITY.MODEL" structtoxml v_xml, v_struct In the component, which recieved the struct: xmltostruct v_struct, v_xml structtocomponent v_struct->ENTITY.MODEL ; The model name is essential By this way, you can exchange complete tree of data model between components, but you need an entity at top of component.


    Author: Philippe (philippe.grangeray@agfa.com)
  7. diseli said Hi Iain, Which version 9.5 patch level do you use?

    Patch 114. So right in the middle of this.... Laugh There will almost certainly be empty boolean values in the data stored. So that looks likely to be the issue. I still have the issue with recovering the data (almost regardless of how I store it) of it coming back requiring validation. I currently use getlistitems/occ/init when getting the data from valrep strings, and then release to reset the requirement to validate the key fields, but it results in reams of code which have to be maintained. I'm looking for a nice self managing method of storing the data and recovering it.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)