我希望了解sesame的sail-interface如何处理SPARQL更新语句（ADD，COPY，...）以及如何将其传播到该接口的实际实现。
例如，SPARQL ADD语句是否由SailUpdateExecutor类中的executeAdd方法实现是正确的？ 请参阅https://bitbucket.org/openrdf/sesame/src/aa0dd3b04738e707c582e4dda14a0a0c5a77ab51/core/repository/sail/src/main/java/org/openrdf/repository/sail/helpers/SailUpdateExecutor.java?at=master&fileviewer=file-view-default。
如果这是正确的，我是否正确解释SAIL图层从源图表中每次三次提取三次并将其插入目标图形？
如果是这样，是否可以为SAIL实现覆盖此行为？ 例如，我认为通过本机批量索引操作可以在nativeRDF存储上有效地实现此操作？通用实现不能利用内部数据结构的任何好处，因此执行将不是最佳的。
如果在sail界面中没有预见到这一点，是否有任何SESAME查询接口应用此策略：尽可能多地将查询推送到商店？或者策略是相反的：当可以探索查询时，它立即完成。
最后，可以调整查询执行策略吗？我在源代码中找到了对查询执行优化器的引用，但是我找不到它们是否可以按商店实例配置？
赞赏
答案 0 :(得分：1)
SPARQL ADD语句是否由SailUpdateExecutor类中的executeAdd方法实现是正确的？
这是正确的。
我是否正确解释SAIL图层从源图表中每次三次提取三次并将其插入目标图形
是的，这是默认实现。
但是，请注意底层商店如何选择实际处理插入的数据。它可以简单地在它们进入时添加三倍三倍，或者它可以选择以对该特定商店最有效的任何方式将事物一起批量处理。这就是为什么UpdateContext对象与实际插入一起提供的原因 - 它是一个标记对象，它通知底层存储这些插入属于同一个整体更新操作。
如果是这样，是否可以为SAIL实现覆盖此行为？例如，我认为通过本机批量索引操作可以在nativeRDF存储上有效地实现此操作？通用实现不能利用内部数据结构的任何好处，因此执行将不是最佳的。
如上所述，底层存储可以在SailConnection方法实现中执行此操作，这些实现具有UpdateContext对象作为其参数之一。
SailUpdateExecutor仅在逻辑级别执行更新。优化其执行仍然完全取决于底层商店。
如果在sail界面中没有预见到这一点，是否有任何SESAME查询接口应用此策略：尽可能多地将查询推送到商店？或者策略是相反的：当可以探索查询时，它立即完成。
我不太确定我会关注，但查询总是被完全推送到底层商店。事先发生的唯一事情是查询被解析并转换为代数模型。该代数模型被发送到底层商店，该商店可以完全自由地以其喜欢的方式优化/转换/执行它。当然，为方便起见，提供了默认评估策略，但可以覆盖该策略。
最后，可以调整查询执行策略吗？我在源代码中找到了对查询执行优化器的引用，但是我找不到它们是否可以按商店实例配置？
大多数Sail商店实例不会使这些优化器可配置 - 他们只是在内部按照自己的意愿应用它们。这种情况通常在SailConnection.evaluate方法中发生（通常在AbstractSailConnection.evaluateInternal中）。这也是商店实现可以选择使用的评估策略（默认或自己的优化策略）。