restart of loader needed when changing meta data of a form (measure ..)

[Said Bouzenzana@B.I.]

Dear Jiri,
The loader is using cache to avoid database access but the drawback of this , is that when changing the structure of a form such as adding a measure or changing its type , something that my happened , we've got following error message :
<error>
<external>
An application error has occurred, please contact Technical Support. [Invalid measurement type parameter: MSRTY_RS112__D_RS-DDC_RS-DDC-PC]
</external>
<internal>
Invalid measurement type parameter: MSRTY_RS112__D_RS-DDC_RS-DDC-PC
</internal>
<errorType>
APPLICATION</errorType>
</error>

After a restart of the loader everything went fine .
As we will probably increase the possibility to change forms or to add measure via the web interface we need to avoid this

[Jiri Dvorak (jiri-dvorak)]

All DAO/DTO values should be cached per-session only, not centrally, so a simple logout / login should "fix" the problem.

If that is not enough, the next step is to re-generate the DAO/DTO objects, and disable the caching in object's definition - however, that will have negative performance impact.

[Said Bouzenzana@B.I. (said-bouzenzana)]

Ok Jiri ,
We will definitely choose the solution disabling the cache but could you please give us info about how to do it .
Thanks a lot
Best Regards
Said

[Jiri Dvorak (jiri-dvorak)]

The fastest, easiest and "proper" way to refresh the cache (and also to avoid any long-running JDBC connections) is to LOGOUT and then LOGIN again, immediately before submitting the next "batch" of data to be loaded. That will allow you to use a 100% identical code base as FLUID, and will preserve most performance optimizations. The performance overhead of LOGOUT/LOGIN is fairly low, even if you'd do it after each e.g. 500 processed rows, it will not slow down the loader process too much.

Should this not be feasible for some reason, the second best way is to edit package intl.who.gim.data.ormgen, class WHOGIMORMGen, and in the table sqlObjectsToGenerate[], change each column "option-codes" (= 4th column) from "CACHE_PK" to null; or you can do that only for the classes that are giving you a hard time. After that, re-generate all DAO and DTO objects, by running the class WHOGIMORMGen. This will disable all caching, but expect some performance slowdown.