基本上,我们的想法是为两个不同的底层数据库使用相同的hibernate映射文件。在生产中,底层数据库是MySQL5,出于测试目的,我想使用Apache Derby - 以避免为了测试目的而设置和维护各种MySQL数据库。
我希望只需切换DataSource的驱动程序并更改一些参数就可以完成这项任务,但我已经遇到了一些小麻烦。所以实际上有两个问题。第一个具体问题是:
予。如果数据类型在MySQL中可用且不在Derby中,是否可以告诉Derby使用哪种数据类型。映射如下:
<property name="about">
<column name="`about`" not-null="false" sql-type="text"></column>
</property>
Derby不知道sql-type“text”所以它拒绝创建表。它是Derby 10.4.2.0和Hibernate 3.2.6。顺便说一句。
II。您在使用两个不同的数据库进行测试和生产时有什么经验?我知道有一些缺点,例如您无法测试存储过程或特定于数据库的查询 - 但另一方面,它使测试更容易,更快(如果您最终运行它)。你觉得怎么样?
答案 0 :(得分:3)
问题#1 - 不指定sql类型;改为使用Hibernate type:
<property name="about" type="string" length="4096"/>
然后,您可以扩展Hibernate提供的Derby(或MySQL)方言,以根据(未)指定的长度将该类型映射到适当的DB类型。看一下MySQLDialect的例子;它根据长度将字符串类型映射到varchar
或text
类型之一。
问题#2 - 您的意思是为开发和生产使用不同的数据库吗?因为使用不同的数据库来进行测试和制作就像玩满载桶的俄罗斯轮盘 - 你不会赢: - )
您始终需要测试所有适用的部署配置。如果你确实需要同时支持开发和生产,使用不同的数据库并不是一个糟糕的方法,因为它有助于尽早找到可移植性问题。
答案 1 :(得分:1)
在我看来,在测试中使用不同类型的数据库的主要原因是更快的单元测试,假冒或模拟数据库是不切实际的(尽管你可以做到后者)。请注意,应该有一个暂存会话,其中测试可以针对生产类型的数据库运行,以确保您不编码到测试数据库。它还会强制您编写一个通用数据库 - 有时这是一个好主意,有时则不是。
显然,如果你需要一个特定于数据库的函数(存储过程甚至是特殊类型),你应该使用相同的类型。
对于MySQL,您可以将测试中的表设置为stored in memory。如果您可能需要MySQL特定项目作为选项。如果目标是数据库通用而不是在开发中使用不同的数据库/低级别测试可能是一件好事。
答案 2 :(得分:1)
在不同的环境中使用不同的数据库供应商应该没有问题(注意ChssPly76的答案,TEST和PROD应该是相同的)。虽然我还没有尝试过Derby。
就个人而言,我喜欢将HSQLDB用于DEV环境。它小巧,灵活,便于携带,几乎不需要设置。使用像Unitils这样的工具将Hibernate,DbUnit和JUnit粘合在一起对我来说非常好。在执行JUnit测试之前,HSQLDB加载了静态测试数据。这允许数据访问层JUnit测试具有基于实际数据的断言(它是从位于测试附近的一些xml文件加载的)。
(Unitils的一个注意事项是默认的“loadStrategy”是在加载之前删除所有现有数据,所以在你指出那个东西时要小心。)
答案 3 :(得分:0)
根据我的经验,您测试的数据库实现越多,您就越早发现任何您不小心依赖于跨数据库无法移植的地方。
如果Derby让您的测试变得更快更容易,那么这是一个很好的结果,因为更快更容易的测试会鼓励更多的测试。
我认为Derby是测试的绝佳选择,因为Derby非常努力地遵循SQL标准并且只支持标准中指定的语法和行为,所以这应该有助于确保您避免使用非标准数据库功能。
但我同意,当您接近部署应用程序时,您需要使用尽可能接近预期部署配置的配置对其进行测试。