0

我想知道为什么 derby 不考虑在给定数据源（当前示例为 WAS）上定义的属性“currentSchema”？

我的问题与 Nastya 在这篇文章中的问题完全相同：在 DERBY 查询中省略模式 但他/她的最后评论没有答案。

所以，我有一个应用程序处理不同的数据源（相同的数据库，但每个数据源一个模式）。我认为如果我告诉 Derby 使用该数据源，Derby 将使用在数据源上定义的属性“currentSchema”，但是我所有的命名查询都是在模式“DEV”（数据库用户名）上执行的，而不是在我的数据源属性中定义的模式上执行'当前架构'。我知道当查询没有提供模式并且之前没有执行 SET CURRENT SCHEMA 语句时，这是 derby 默认行为，但是......

是否有任何现有的解决方案或即将改进的 Derby 来解决这个用例？（我不认为这是一个问题，因为我认为 Derby 的设计目的是为每个用户使用一个模式）

提前感谢您的任何建议。

PS：要理解我为什么需要这个：我已经编写了脚本来自动将 derby 数据源配置到开发人员的工作站（本地 websphere）中，以便他们可以将他们的应用程序部署/运行到本地数据库而不是常见的 DB2 开发数据库中。但是我会避免在应用程序代码中的每个请求之前执行 SET CURRENT SCHEMA 语句，只是为了解决这个问题......（对其他真实环境的性能影响）当然我不能更改本地数据库以使用除 Derby 之外的其他东西 :)

4

1 回答 1

0

我找到了一个特定于我的用例的解决方案，因为修复是通过 WebSphere 配置完成的。

解决方案：将数据源配置为自动执行 SQL 查询，以验证来自该数据源的新连接池。SQL查询是

SET CURRENT SCHEMA MY_SCHEMA

其中“MY_SCHEMA”特定于每个数据源。

这当然可以通过更新使用 wsadmin 脚本来配置：

  • 数据源上的 J2EEResourceProperty 'preTestSQLString'，值 = SQL 查询
  • 值为“true”的数据源池的“testConnections”属性

如果没有特定的服务器环境（如 WebSphere）在新的连接池上自动执行 SQL 查询，我担心这是不可能的，除非在代码中使用 EntityManager 生产者执行此操作。但这意味着您必须编写特定于您的环境的代码，这不是......很好。

于 2013-09-30T08:11:08.223 回答