@SequenceGenerator 与 DerbyEmbedded 问题
我实际上正在尝试学习 JPA,但我在使用 @SequenceGenerator 时遇到了一些麻烦。
我正在将 derby Embedded 数据库与 EclipseLink 结合使用,并尝试将 SequenceGenerator 注释应用于 Person 实体的 id。
这是我为此使用的代码:
@Id
@SequenceGenerator(name="Person_SEQ", allocationSize=5, initialValue=1)
@GeneratedValue(strategy=GenerationType.SEQUENCE,generator="Person_SEQ")
private int id;
现在的问题是,每当我“第一次”启动应用程序(这意味着我删除以前创建的数据库并重试)时,我都会收到此异常:
[EL Warning]: 2011-09-17 22:25:03.649--ServerSession(31484215)--Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLSyntaxErrorException: SEQUENCE 'PERSON_SEQ' does not exist.
Error Code: 30000
Call: VALUES(NEXT VALUE FOR Person_SEQ)
Query: ValueReadQuery(sql="VALUES(NEXT VALUE FOR Person_SEQ)")
此行为正常吗?
______________________________
我检查了生成的 createDLL.jdbc,这是它给出的有关 Person 表的内容:
CREATE TABLE PERSON (ID INTEGER NOT NULL, FIRSTNAME VARCHAR(255), LASTNAME VARCHAR(255), NONSENSEFIELD VARCHAR(255),PRIMARY KEY (ID))
CREATE SEQUENCE Person_SEQ INCREMENT BY 5 START WITH 5
这让我想知道为什么它以 5 而不是 1 开头?
____________< /em>________
我还发现,当重新启动应用程序(这次使用相同的数据库)并插入一些新人员时,id 会从allocationSize 跳得很远。为了让我自己清楚,这是我经历过的场景:
- 我在第一次执行中插入了 29 个人,这创建了一个从 1 到 29 的 id 池。
- 在第二次执行中(关闭应用程序并重新启动它之后) )我还插入了 29 个人,创建了一个从 71(而不是 30 !!)到 99 的 id 池,
这个问题是由于 derby 嵌入式驱动程序造成的吗?或者我还缺少其他东西吗?
I m actually trying to learn JPA, and i'm having some trouble with @SequenceGenerator.
I'm using the derby Embedded database with EclipseLink and I'm trying to apply the SequenceGenerator annotation to the id of a Person Entity.
Here's the code i'm using for that:
@Id
@SequenceGenerator(name="Person_SEQ", allocationSize=5, initialValue=1)
@GeneratedValue(strategy=GenerationType.SEQUENCE,generator="Person_SEQ")
private int id;
now the problem is that whenever i launch the application "for the first time" (that means that i remove the previously created data-base and retry), i get this Exception:
[EL Warning]: 2011-09-17 22:25:03.649--ServerSession(31484215)--Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLSyntaxErrorException: SEQUENCE 'PERSON_SEQ' does not exist.
Error Code: 30000
Call: VALUES(NEXT VALUE FOR Person_SEQ)
Query: ValueReadQuery(sql="VALUES(NEXT VALUE FOR Person_SEQ)")
Is this behavior normal?
______________________________
I ve checked the generated createDLL.jdbc and here's what it gives concerning the Person Table:
CREATE TABLE PERSON (ID INTEGER NOT NULL, FIRSTNAME VARCHAR(255), LASTNAME VARCHAR(255), NONSENSEFIELD VARCHAR(255),PRIMARY KEY (ID))
CREATE SEQUENCE Person_SEQ INCREMENT BY 5 START WITH 5
which makes me wonder why did it start with 5 instead of 1?
____________________________________________
I've figured out also that when restarting the application (this time with the same database) and inserting some new persons the id jumps so far from the allocationSize. To make my self clear here's the scenario i've passed through:
- i've inserted 29 persons in the first execution, which created a pool of ids starting from 1 to 29.
- in the second execution (after shutting down the application and relaunching it) i also inserted 29 persons, which created a pool of ids starting from 71 (instead of 30 !!) to 99
is this problem due to the derby embedded driver? or am i missing something else?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
错误很可能只是一个警告,EclipseLink 正在检查序列是否存在,并可能在不存在时创建它。
使用 5 开头是因为第一次分配序列时应返回 5,这意味着 JPA 可以使用 1-5,因为预分配大小为 5。
跳转到 71 很可能是由 Derby 缓存引起的服务器上的序列 ID。如果您愿意,您也可以在 DDL 中设置缓存选项,但不应该有任何漏洞问题,通常预分配大小越大越好。只要确保您的 id 使用 long,而不是 int。
There error is most likely just a warning, EclipseLink is checking if the sequence exists, and probably creating it when it does not.
The start with of 5 is used because the first time a sequence is alloacted it should return 5, meaning that JPA can use 1-5, because of the pre-allocation size of 5.
The jump to 71 is most likely caused by Derby caching sequence ids on the server. You can probably also set a cache option in the DDL if you wish, but there should not be any issues with holes, normally the bigger the pre-allocation size the better. Just ensure you use a long for your id, not an int.