升级到1808后，我们终于为客户的SAP Cloud中的自定义业务对象启用了"单一持久性"。

这是什么意思？

如果我们现在谈论单个持久性，那么很明显，在1808年之前，我们有多个持久性。

主要持久性是由业务对象（BO）本身定义的持久性。我们的快速搜索基础设施（FSI）以性能的方式执行查询时使用了辅助持久性。

但是在保持此辅助持久性与业务对象的主持久性中的数据同步方面存在一些问题。谁从来没有过这样的问题？

此外，由于此辅助持久性已针对搜索进行了优化，因此需要从辅助持久性转换数据，甚至需要对主持久性进行读取访问。

从现在起，FSI将直接访问business objects的主持久性中的数据。因此，包括返回结果在内的查询执行速度比以往任何时候都快。

我们是如何做到的？

单一持久性是指FSI搜索到的数据是从业务对象存储的相同数据，也是任何检索返回的相同数据。

这意味着节点的定义必须与数据库表的定义相适应。记住这句话。

为什么不是这样？

我相信大家都知道（也不喜欢）这条消息：

这条消息是针对每个基于字符的数据类型提出的，没有长度限制，因为数据库中的定义被CHAR255替换了。

这条消息现在不见了。我们在数据库级别上使用GDT的定义。

您现在可以（理论上）在所有这些数据类型中存储无限数量的字符！！！

但是没有什么是免费的。

有什么限制？

由于节点的定义与数据库表的定义相匹配，一些以前只在数据库上实施的限制现在成为了运行时的一部分。

一个是并非所有GDT都摆脱了长度限制（标识符，另一个是无限制GDT的使用

连同数据库中关于长度限制的消息，过去和现在都有另一个消息

由于节点的定义与数据库表的定义相匹配，因此此限制现在在运行时强制执行。现在是真正的无限GDT，所有数据库在搜索这样的数据类型时都会遇到问题。

如果您在预定义查询QueryByElement中使用这样一个GDT类型的元素，您将得到一个dump。

这些查询最初-由于其定义的类型-仅用于测试原因（因为它们仅限于自己的节点和数据库）只有通用的、未优化的实现可用）。但我知道它们是常用的。

解决这个问题的方法是使用查询生成器定义的"真实"查询。对于这些查询，企业应用管理，我们克服了数据库问题，并对元素进行了特殊处理，因此甚至可以进行通配符搜索。只需在原始节点下创建一个查询，返利，包括该节点的所有字段，使用此查询而不是QueryByElement。

由于标识符在数据库中持久化的特殊方式，它们仍然被限制为CHAR255。

由于节点的定义与数据库表的定义匹配，大数据 数据分析，此限制不仅在数据库中有效，而且在运行时也有效。这意味着责任。元素或变量不能包含超过255个字符。一般来说，您不会有任何损失，因为持久性之前已经为此类标识符切割了数据。

老实说：您是否曾经需要超过255个字符的标识符？

我们发现唯一需要更长标识符的情况是，这是一个统一资源标识符（URI），指向互联网上的地址，游戏返利平台，如上面消息中列出的WebURI。请注意，即使在这里也存在一些限制，例如Microsoft Explorer支持的URI最大长度为2083个字符。

由于这些元素在运行时被切断，因此无法在脚本中构建更长的WebURI并将其移交给UI或Web服务或其他使用者。

对于这种情况，我们定义了一个不受限制的\u WebURI将随修补程序集合2一起提供。

我们建议在BO定义中与注释瞬态一起使用它，微淘客，因为此标识符不应像所有其他不受限制的数据类型一样用于查询。

此元素将得到特殊处理，因此在运行时不会被切断。当然，如果在QueryByElement中使用，它会转储。

Summary

使用单一持久性，查询执行速度更快，可以存储长度超过255个字符的字符串，但是如果在QueryByElement中使用，这些元素会转储。解决方案是使用查询生成器定义查询。标识符保留255个字符的限制，现在甚至在运行时也是如此。如果您需要更长的WebURI，请使用无限的\u WebURI（从HFC 2开始提供）。

HTH，Horst

PS：由于我不再支持合作伙伴开发基础设施，这将是我为tag SAP Cloud Applications Studio撰写的最后一篇博客。我将不再定期监控标签，但仍然会回答直接以我的名字提出的问题。