Experience with persistence classes

[Former Member]

Hi,

we consider to use the Object Service for the developing.

- Has anybody positive or negative experience with the Persistence Class?

- What's about bull processing?

I have make same tests with the persistence class:

- create a persistence class for a DB-table

- modify a generated SET-method with a validity check

- add a new field to the DB-table

- modify the persistence class by adding this field

-> the modify SET-method for the other field is overwritten

How can i add own validly checks in the SET methods?

Regards,

Stefan

Message was edited by: Stefan Gerschler

[Former Member]

Hi, you can enter into change mode and change the SET method which generated by system.

Where is your problem?

Thanks a lot

[Former Member]

Hi Zhenglin,

thanks for your reply.

Yes, I can change it. But when I expand my DB-table by adding a new field, I have also to enter this field in persistence class.

Unfortunately all SET- and GET- methods seems to be overwritten by the new generated code.

So I will losing the changes.

Thanks,

Stefan

[Former Member]

Hi, as I know, the change on the Persistent table will impact on the class. So if the table changed, the class need to be regenerate definitely.

If the code lost is the point your concern, I think you can copy the class to a new one.

And change the table, regenerate the Persistence Class, and copy back the code of method.

Thanks a lot

[Former Member]

Check this weblog: /people/thomas.jung3/blog/2004/12/08/abap-persistent-classes-coding-without-sql

Regards,

Subramanian V.

[Former Member]

Hi Subramanian,

thanks for this very interesting Weblog .

But I still don't understand if it is OK to change the generated SET-/GET Methods.

Thanks,

Stefan

[Former Member]

Hi, It looks impossible to change associated TABLE/STRUCTURE of the Persistence Class. But if change the defination of the TABLE/STRUCTURE, can the change reflect into the Persistent Class? As some authority problem, I can't do a test on my server, maybe need to negotiate with my administrator.

When get the authority, I will have a try.

By the way, what's the problem you are bored in?

Concern that if change the defination of TABLE, your code in the SET/GET method will lost?

[Former Member]

Hi,

thanks a lot for your efforts.

Exactly your last sentence is my fear.

We are in an early stadium of modeling, but we will already realize some classes in the SE24.

When i code a validly-check in a generated SET-method for an existing attribute and the modeler expand the class with a new attribute, I have put this attribute in the table/structure and make a new generation of the persistent-class ... and will lose my code for the validly-check

Would it by a better idea to use this class as a superclass and overwrite the SET-method in subclass?

I'm not sure would be the practicable way to do this.

[Former Member]

Hi, Stefan Gerschler

I have tried the test. It looks our code will lost after the new fields added on the table.

So I think we should copy the Persistent Class before change on the fields. After regenerate the Persistent Class, copy the method code back to the SET.

That's the solution in my opinion.

Hope it will be helpful.

thanks a lot

[Former Member]

Hi Zhenglin,

thanks for your answer and your efforts.

This a workaround, but this is still a source of defect, when a developer forget to do this manually steps.

A missing validity check in the productive system can have bad effects.

I will close the quote next time, but i still hope that somebody have an official procedure without copying. Is something planned in the next releases?

Is is unusual to make validity checks in a SET-method?

Stefan

[Former Member]

hi, Stefan Gerschler

I'm glad to tell you, that your superclass idea can help us to achieve the target you want.

I try is as following:

1. uncheck the 'Final' flag in the old class attribute. if not, the class can't be inherited.

2. create a class, with inherit from old class. Then the old method can be kept with no change.

3. change the defination of our table, E.G. add a new field. You can see as the SET/GET method inherit from superclass, when add new SET/GET in the subclass, the code in superclass won't be changed.

4. As the new class is defined as Persistent Class too, you should delete the IF_OS_STATE interface of itself, just left the inherited one. (an interface can't be implemented repeatly).

5. Now you can call the method of subclass and superclass.

As the inherit relation, the superclass method will be called smoothly. Your target achieved.

Hi, your idea is critical for solve this problem.

Thank a lot

Hope it will be helpful

Message was edited by: zhenglin gu