You could try setting a break point in the database update code and some in
the event handlers and the examine the call stack to see where the call
originates from and in which order things happen
--
Chris
On Tue, Jan 16, 2018 at 10:51 AM, JumpStart <
geoff.callender.jumpst...@gmail.com> wrote:
> If Hibernate is creating/updating the database definition then you could
> be right. I’m not sure because I use this kind of thing for alternate key:
>
> @Entity
> @Table(name = "Users", uniqueConstraints = { @UniqueConstraint(columnNames
> = { “username" }) })
> public class User ...
>
>
> > On 16 Jan 2018, at 5:42 pm, Christopher Dodunski <ChrisFromTapestry@
> christopher.net.nz> wrote:
> >
> > Hi Geoff,
> >
> > Sorry, I'll try that when back at my PC tomorrow.
> >
> > I could be mistaken, but does the 'column' annotation below not set the
> > USER_NAME column in the database as unique? I assumed this is the reason
> > for the ConstraintViolationException, i.e. the unique field.
> >
> > Irrespective, I'll do as you suggested in onActivate() and see what
> > results. :-)
> >
> > //@NaturalId
> > @Column(name="USER_NAME", nullable=false, unique=true, length=50)
> > @Validate("required")
> > @NotNull
> > @Size(min = 4, max = 50)
> > @Alphanumeric
> > private String userName;
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
>
>
