Improving persistent class performance with on-demand DB reads?

pokrakam — Sat, 05 Sep 2009 11:58:09 GMT

Hi,

Something that has been troubling me for some time is the data access design of persistent classes. A persistent class loads the ENTIRE data set when it is instantiated.

To me this defeats one of the advantages of get/set methods. What I would like is to be able to read data when it is first accessed.

For example: A purchase order header can be loaded in a few ms. However with items it can take 10 times as long - even more if the items are implemented as persistent classes themselves. If items are only needed half the time, a significant performance gain is realized by only reading items the first time the GET_ITEMS method is called. In my own persistence implementations using BI_PERSISTENT (Nothing to do with ABAP Persistent Classes), I implement this using private attributes to buffer data, along the lines of:

method get_items. 
  if m_items[] is initial. 
    m_items = <read and/or instantiate items>. 
  endif.
  re_items = m_items.
endif.

Using ABAP Persistent Objects this does not appear to be possible since they insist on loading everything up front in the DB mapping or IF_OS_STATE~INIT methods. Is some kind of on-demand reading possible using ABAP Persistent Classes?

Any input appreciated

Cheers,

Mike

Re: Improving persistent class performance with on-demand DB reads?

pokrakam — Thu, 15 Apr 2010 11:54:58 GMT

Closed thread due to lack of interest.

I still haven't gotten around the issue so will happily reopen if anyone has any input as I am still interested in the topic.

Re: Improving persistent class performance with on-demand DB reads?

Former Member — Sat, 01 Oct 2011 23:52:20 GMT

Hi Mike,

yes, I am also very interested in this topic. While developing my first (and only a mid-complex) persistence application, I am expecting slightly different behaviour of linked persistent objects than you described above. According to the book 'Object Services in ABAP' and lazy loading paradigm mentioned there, the referenced persistent objects should be instantiated as representative objects only, containing no data, and the data should be physically loaded from database only once it's really needed (ie. accessed or explicitly instantiated). This should be the approach preventing the situation of mass chained instantiation of many linked persistent objects where most of them will not be needed, probably.

This is what they say about instantiation of persistent objects that are linked by persistent references.

However, since the persistent objects do not allow creating of 1:N relationships (classics: HEADER->ITEMS) via persistent references automatically, then this kind of relationship has to be maintained manually and therefore I expect you having full control of when it is accessed and instantiated for the first time...? What I want to ask here is then: is there any suitable approach which allows to maintain 1:N relationship fully or semi-automatically and which (as a disadvantage) makes the problem for you with 'full' instantiation? Am I missing something? There are also some threads regarding persistent mapping of table-like attributes, but no relevant answers (this should solve my problem as the table of persistent references could be saved then).

Until now, I have found almost nothing about how the 1:N relationship should be correctly built (only 1:1 or M:1 is supported via persistent references), so I am applying the following approach in my app. Any comments are welcome (excuse some typos, as this is written in Notepad, not on the running system):

 
ref_header = zca_header=>agent->create_persistent( ).
guid_of_header_class = ref_header->get_cl_guid( )."cl_guid is set in IF_OS_STATE~INIT
guid_of_header_instance = 
  zca_header=>agent->if_os_ca_service~get_oid_by_ref( ref_header ).
ref_header->set_inst_guid(                   "keep header inst. ref. for future lookups 
i_inst_guid = guid_of_header_instance 
).             
lt_r_items = ref_header->create_items(       "lt_r_items = table of items references
  i_cl_guid = guid_of_header_class
  i_inst_guid = guid_of_header_instance
  it_items = lt_items )

and the method zcl_header->create_items then looks somewhat like this:

 
loop at it_items assigning <it_items>.
  ref_item = zca_item=>agent->create_persistent( ).
  ref_item->set_cl_guid( i_header_cl_guid = i_cl_guid ).
  ref_item->set_inst_guid( i_header_inst_guid = i_inst_guid ).
  ref_item->set_some_other_attrib( 
    i_some_other_attrib = <it_items>-some_other_attrib 
    ).
  append ref_item to rt_r_items.             "rt_r_items = table of items references
endloop.

I have created a secondary index on items for header_cl_guid and header_inst_guid. This is used during the re-load of already saved items for particular header entry. Query service is used with header_cl_guid and header_inst_guid of actual header entry as filter criteria for item pesistent objects and table of item references is returned. Thus the instance attribute lt_r_items of ref_header is filled with references to relevant items again.

Thank you

Michal

topic Improving persistent class performance with on-demand DB reads? in Application Development and Automation Discussions

Improving persistent class performance with on-demand DB reads?

Re: Improving persistent class performance with on-demand DB reads?

Re: Improving persistent class performance with on-demand DB reads?