简体   繁体   English

运行时类型服务 (RTTS) 是否使用数据库来获取数据描述?

[英]Do Runtime Type Services (RTTS) use database to get data descriptions?

Question

Do methods like describe_by_data , get_ddic_field_list , get_components (of cl_abap_typedescr and similar), retrieve data from database or does it get generated on application server?describe_by_dataget_ddic_field_listget_componentscl_abap_typedescr和类似的)这样的方法是从数据库中检索数据还是在应用程序服务器上生成?

I looked at those classes and all of the some methods (that populate cache, presumably) appear to pull data in non-standard ways ( METHOD ... BY KERNEL MODULE ... ) and others pull data from cache.我查看了这些类,所有一些方法(可能填充缓存)似乎都以非标准方式( METHOD ... BY KERNEL MODULE ... )提取数据,而其他方法则从缓存中提取数据。 I am wondering how it gets pulled if it is not cached.我想知道如果它没有被缓存它是如何被拉出来的。

Google didn't give me any concrete info on this topic either.谷歌也没有给我任何关于这个话题的具体信息。

Some context, in case details become relevant一些上下文,以防细节变得相关

I've been looking into implementing dynamic select clauses generation for some generic classes (to replace asterisk for column-based processing in S/4HANA and hopefully reduce the strain on DB).我一直在研究为一些通用类实现动态选择子句生成(以替换 S/4HANA 中基于列的处理的星号,并希望减少 DB 的压力)。

Since most of those classes retrieve data into dictionary type structures, I figured I could use type descriptions of Runtime Type Services (RTTS), to get the field lists and dynamically generate the select clause based on target structure.由于这些类中的大多数将数据检索到字典类型结构中,我想我可以使用运行时类型服务 (RTTS) 的类型描述来获取字段列表并根据目标结构动态生成选择子句。

In most cases I can work around performance loss (if there is any) by implementing static variables (and only processing it once per session), but I've ran into similar cases where static variables were not an option (processing is made on unknown types) and I had to abandon the idea because I wasn't sure how it would impact the peak performance if those methods were called, let's say 30 times per session.在大多数情况下,我可以通过实现静态变量(并且每个会话只处理一次)来解决性能损失(如果有的话),但是我遇到过类似的情况,其中静态变量不是一个选项(处理是在未知的类型),我不得不放弃这个想法,因为我不确定如果调用这些方法会如何影响峰值性能,假设每个会话 30 次。

Edit (just a piece of code, to avoid further confusion that leads to condescending comments with no substance):编辑(只是一段代码,以避免进一步混淆导致没有实质内容的居高临下的评论):

lo_struct ?= cl_abap_structdescr=>describe_by_data( header ).
ct_components = lo_struct->get_components( ).
"Loop through ct_components appending names to lv_select_clause

lv_select_clause = get_header_fields( is_target_structure = header ).
select single (lv_select_clause)
  from rbkp
  where gjahr = @iv_gjahr
    and belnr = @iv_belnr
  into corresponding fields of @header.

I can't be sure for the latest ABAP versions, but that ABAP Dictionary stuff (AKA "DDIC" for Data Dictionary) originates from the database tables DDNTT and DDNTF (also called "nametab", and its elements are called the "database runtime objects") which are filled during activation of DDIC objects (tables and so on, those tables are DD02L, DD03L, as said by @icbytes, and so on).我不能确定最新的 ABAP 版本,但是 ABAP 字典的东西(数据字典的又名“DDIC”)源自数据库表 DDNTT 和 DDNTF(也称为“nametab”,其元素称为“数据库运行时”对象”)在激活 DDIC 对象(表等,这些表是 DD02L、DD03L,如@icbytes 所说,等等)期间填充。

When they are queried, they are also transferred and persisted in every application server memory.当它们被查询时,它们也被传输并持久化在每个应用服务器内存中。 This memory is called the nametab buffer .此内存称为名称表缓冲区 The newest data are replacing the oldest data when the buffer is full.当缓冲区已满时,最新的数据将替换最旧的数据。

No idea about the performance, but no doubt that it can be neglicted compared to the SELECT you do right after.不知道性能,但毫无疑问,与您之后执行的 SELECT 相比,它可以忽略不计。

One more thing, about RTTS, always use the GET_* methods rather than the CREATE_* ones because they are faster (they behave slightly differently, but generally only experienced developers may need to use the latter ones).还有一件事,关于 RTTS,总是使用 GET_* 方法而不是 CREATE_* 方法,因为它们更快(它们的行为略有不同,但通常只有有经验的开发人员可能需要使用后者)。

If you want, you can add another layer of memory, but I guess it's not worth doing it (more developer time spent + more memory consumed versus no big performance improvement).如果你愿意,你可以添加另一层内存,但我想这样做不值得(花费更多的开发人员时间 + 消耗更多的内存,而没有大的性能改进)。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM