Updating linked fields in a persistent class

[pokrakam]

Hi all,

If a field of a persistent class is updated, what is the best way to update a related field?

Scenario:

A persistent class with public GET/SET access to a table field STUFF, and public GET access to a field CATEGORY.

Whenever SET_STUFF is called from the outside, the class should also re-evaluate and update CATEGORY.

The easiest is to modify the SET_STUFF method to determine the new category and update it if necessary. However GET/SET methods are always overwritten whenever the class is regenerated, which happens all too easily. Can this be done a bit more elegantly?

Most modifications can be done by redefinitions of the agent class and do not get overwritten each time the class it regenerated. e.g. I have done something similar by redefining the DB access methods to update various fields, but for my current requirement the update needs to be immediate, not during save.

Any input appreciated,

MIke

Edited by: Mike Pokraka on Sep 15, 2009 4:12 PM

[naimesh_patel]

Updating the field CATEGORY immediatly would lead to some problems while working with Persistent class because of the COMMIT WORK. As soon as COMMIT WORK after the CATEGORY's "save" hits, all pending save request would execute and may update some fields which you don't want to update at that point of time. To overcome this problem, you might determine the CATEGORY temporarily and save it when application exists.

You can create a class which is one layer above then the Persistent class to determine the CATEGORY whenever the SET_STUFF has been called. This class should handle all the operations SET/GET with your persistent class.

Regards,

Naimesh Patel

[pokrakam]

Hi Naimesh,

>

> Updating the field CATEGORY immediatly would lead to some problems while working with Persistent class because of the COMMIT WORK. As soon as COMMIT WORK after the CATEGORY's "save" hits, all pending save request would execute and may update some fields which you don't want to update at that point of time. 

No COMMITs should be performed, that's part of what I'm trying to accomplish. STUFF may change several times during the lifetime of the process and CATEGORY must change with it. When the application finally does a COMMIT WORK then both are written to the DB. (In fact my real scenario involves both transient and persistent instances and multiple callers).

My objectives are to have a readonly attribute in the persistent class that changes in response to other fields changing. It should behave as though the app is calling a SET_STUFF and a SET_CATEGORY, but the persistent class must retain control of the CATEGORY field as several applications can modify STUFF.

My current workaround is an UPDATE_CATEGORY method that must be implemented by each caller, so it works. Layering another class above it an option but is a bit of overkill which also makes it a workaround.

I have found that EXT_HANDLER_WRITE_ACCESS seems to provide something, but the comments in there seem to indicate I shouldn't modify the object info. Unfortunately I have run out of time to experiment this week so the workaround will have to stay for now, but I'd still be interested in a more elegant solution.

Thanks for the input,

MIke

[Former Member]

Hi,

you cann write your own event handlers for the events

IF_OS_STATE~WRITE_ACCESS

IF_OS_STATE~READ_ACCESS

and set them in IF_OS_STATE~INIT. From there you can check teh value of STUFF and set CATEGORY accordingly.

best regards,

Hans Hohenfeld