1

基本上这个想法是为两个不同的底层数据库使用相同的休眠映射文件。在生产中，底层数据库是 MySQL5，出于测试目的，我想使用 Apache Derby——以避免为测试目的设置和维护各种 MySQL 数据库。

我希望只需切换数据源的驱动程序并更改一些参数就可以完成这项工作，但我已经遇到了一些小困难。所以实际上有两个问题。第一个具体问题是：

I. 如果数据类型在 MySQL 中可用但在 Derby 中不可用，是否可以告诉 Derby 使用哪种数据类型。映射如下：

  <property name="about">
    <column name="`about`" not-null="false" sql-type="text"></column>
  </property>

Derby 不知道 sql 类型的“文本”，因此它拒绝创建表。它是 Derby 10.4.2.0 和 Hibernate 3.2.6。顺便一提。

二、您在测试和生产中使用两个不同的数据库有什么经验？我知道有一些缺点，例如您无法测试存储过程或特定于数据库的查询 - 但另一方面它使测试更容易和更快（如果您最终让它运行）。你怎么看？

4

4 回答 4

3

问题 #1 - 不要指定 sql 类型；改用Hibernate 类型：

<property name="about" type="string" length="4096"/>

然后，您可以扩展 Hibernate 提供的 Derby（或 MySQL）方言，以根据（未）指定的长度将该类型映射到适当的 DB 类型。以 MySQLDialect 为例；它根据长度将字符串类型映射到任一类型varchar或其中一种类型。text

问题 #2 - 您的意思是使用不同的数据库进行开发和生产吗？因为使用不同的数据库进行测试和生产就像玩满桶的俄罗斯轮盘赌——你不会赢 :-)

您始终需要测试所有适用的部署配置。如果您确实需要同时支持这两种数据库，那么使用不同的数据库进行开发和生产并不是一个坏方法，因为它有助于及早发现可移植性问题。

于 2009-11-10T18:59:03.637 回答
1

在我看来，在测试中使用不同类型的数据库的主要原因是为了进行更快的单元测试，在这种情况下伪造或模拟数据库是不切实际的（尽管你应该做后者）。请注意，应该有一个暂存会话，可以在其中针对生产类型的数据库运行测试，以确保您没有对测试数据库进行编码。它还迫使您对通用数据库进行编码——有时这是一个好主意，有时则不是。

显然，如果您需要特定于数据库的函数（存储过程甚至特殊类型），您应该使用相同的类型。

对于 MySQL，您可以在测试中设置要存储在内存中的表。如果您可能需要 MySQL 特定项目，这是一个选项。如果目标是数据库通用而不是在开发/低级测试中使用不同的数据库可能是一件好事。

于 2009-11-10T19:10:58.060 回答
1

在不同的环境中使用不同的数据库供应商应该没有问题（注意ChssPly76的回答是TEST和PROD应该是一样的）。虽然我还没有尝试过德比（还）。

我个人喜欢将HSQLDB用于 DEV 环境。它体积小、灵活且易于携带，几乎不需要设置。使用 Unitils 之类的工具将Hibernate、DbUnit 和 JUnit 粘合在一起对我来说非常有效。在执行 JUnit 测试之前，HSQLDB 会加载静态测试数据。这允许数据访问层 JUnit 测试具有基于真实数据的断言（它是从位于测试附近的一些 xml 文件加载的）。

（Unitils 的一个警告是默认的“loadStrategy”是在加载之前删除所有现有数据，所以要小心你指向那个东西的位置）。

于 2009-11-10T19:22:02.757 回答
0

以我的经验，你测试的数据库实现越多，你就越早发现你不小心依赖于不能跨数据库移植的东西的地方。

如果 Derby 使您的测试更快更容易，那么这是一个很好的结果，因为更快和更容易的测试会鼓励更多的测试。

我认为 Derby 是一个很好的测试选择，因为 Derby 非常努力地符合 SQL 标准并且只支持标准中指定的语法和行为，所以这应该有助于确保您避免使用 non - 标准数据库功能。

但我同意，当您接近部署应用程序时，您需要使用尽可能接近预期部署配置的配置对其进行测试。

于 2009-11-11T17:47:59.817 回答