Persistent classes: hashing generic query requests
Hi to everybody,
This is the third part of my blog about using persisntent classes as a quick tool for generating query classes and convenient reusing of them.
This is the beginning:
Persistent classes: revival of a spirit. Query by range.
and part 2:
Persistent classes: single get( ) method instead of multiple get_xxx() methods calls
Using this query class I figured out that in the case when we use the same request twice, we do the selection every time.
To improve the performance we need to create some buffer for retrieving previously selected requests.
So what we have as incoming parameters: request that is represented by a structure of any type and agent class.
To solve this abstract task I decided to use serialization technique again.
To be honest this is the first time I applied such a logic based on serialization and checksum calculation.
Has anyone used similar methods for generic hashing of anything? What is your opinion about overall performance: frequently called transormations and checksum calculations.
The full example you can find here: ZCL_OS_API
I use this type of cache in a production enviroment and I can tell you: it works and it does not hurt. 🙂
The very first time I used this method more then 15 years ago.
One of our customers had the problem, that they produced configurable good and every configuration should have it's own EAN number. For several reasons, cost/availability/..., they wanted to reuse EAN's of identical configurations, just based on new customer orders.
- normalize configuration in a string (today I would translate to XML)
- create an MD5 hash
- used the hash as key in INDX to store full configuration, in case of hash conflicts, and the assigned EAN. (INDX just because it easily stores blobs)
They still exist and they still produce these types of products, so maybe they still use the code,
Do you speak about standard SAP classes now?
No, pure Z-code. In all cases.
as per the note 3992 saving to INDX table is discouraged by SAP and shouldn't be used anymore