I'm sure other workarounds can be found, but the broader question is whether
OpenJPA should handle this case more gracefully.

Quick googling suggests  that SQLServer identity columns may start with 0 by
default. Other databases may do the same (DB2 does not, I'm not sure about
others).

So while I'd consider starting with 0 to be unusual, I don't think it's
completely unreasonable and may be something that new users hit without
realizing it.

-mike

On Mon, May 4, 2009 at 2:36 PM, Rick Curtis <[email protected]> wrote:

> Try adding a version column to your Entity, or stop using primitives for
> your id columns. OpenJPA does not know the difference between an id that
> has
> a value of zero, and one that is uninitialized.
>
> -Rick
>
> On Mon, May 4, 2009 at 2:26 PM, B.J. Reed <[email protected]> wrote:
>
> > I have a testcase where a DB2 DB is already created.  It has 2 tables and
> > the web user preferences table has an identity column that is defined as
> > "generated always as identity (start with 0, ..."
> >
> > In the test case, I am expecting 2 sets of 2 inserts each into this
> table.
> >  The first 2 objects should have id's of 0 and 1 (works fine) and the 2nd
> > set should have id's of 2 and 3 - what happens is that the web user
> > preference entities have never had their id set so both of their ids are
> > defaulted to 0.  In stead of inserting rows, the entity manager sees the
> id
> > of 0 on both 2nd set objects and then does an update in the DB on the
> very
> > first record (since that one's id correctly is 0).
> >
> > Should OpenJPA be able to handle a generated column that starts with 0 (I
> > can create a JIRA for an enhancement) or is it common knowledge that the
> DB
> > should start with a non zero number or is there something that I should
> set
> > the id to in the new web user preferece entities so that they will always
> be
> > inserted?
> >
> > By changing the DDL to start with 1 in stead of 0, this problem is
> avoided
> > and 4 rows are inserted into the DB properly with id's 1 - 4.
> >
> > --B.J. Reed
> >
>

Reply via email to