Mystery solved!
My original suspicion was correct in that somewhere the app was attemting
to update the database before or while onValidate() was doing it's thing.
It wasn't BeanEditForm however, it was Hibernate jumping in the way. Part
of the stack trace:
And when using the literal "Abel", as below...
User userVerif =
crudServiceDAO.findUniqueWithNamedQuery(User.BY_USERNAME,
QueryParameters.with("userName", "Abel").parameters());
LOG.debug("Verify user: [" + userVerif.getUserName() + "|" +
userVerif.getFirstName() + "|" +
Hi Geoff,
I'm not sure whether this is what you meant, but I added the below code to
my onActivate() method:
User userVerif =
crudServiceDAO.findUniqueWithNamedQuery(User.BY_USERNAME,
QueryParameters.with("userName",
user.getUserName()).parameters());
LOG.debug("Verify user: [" +
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,
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
To summarise...
the exceptions:
org.hibernate.exception.ConstraintViolationException
could not execute statement
SQL
n/a
SQLState
23000
errorCode
1062
and:
java.sql.SQLIntegrityConstraintViolationException
Duplicate entry 'Abel' for key
Below is a snippet of my User entity class, where the NamedQueries are
also located.
Based on your responses, it seems that I'm correct that UpdateUser.java
oughtn't be persisting anything for NamedQuery to discover until the line
"crudServiceDAO.update(user)" is reached in
I’m guessing that if you run that query earlier, for that user, then it would
return the same exception. Try putting it in onActivate and pass it 'Abel'.
Is the query joining entities? Possibly it’s returning a cartesian product of
the user with another entity, ie. more than one entity
Hi Bob,
Evidently, equals is not being reached as there is no output in the logs
from the line containing "LOG.debug("Verify user...)". The log file does
contain the output from "LOG.debug("Form user...)", two lines above.
So my focus has turned to the line containing "User userVerif =
I don't think k you actually answered my question about the equals method
(or perhaps I misunderstood you). I'll try again:
1. Is the line with the recortError() method call actually being reached?
Use a debug breakpoint or log statement to prove it.
2. If not, have you overridden the equals
The database contains these two users:
User name: Abel
First name: Abel
Last name: Tasman
etc.
User name: James
First name: James
Last name: Cook
etc.
As a test I load user 'James' into the BeanEditForm of UpdateUser.java,
and attempt to change his user name to 'Abel' (an illegal change). This
Does the userVerif.equals(user) clause actually result in true? If not,
then recordError wouldn't run, and validation would be considered to have
passed. Check User.java's equals method, or better yet, maybe just compare
the username strings directly.
On Jan 12, 2018 7:04 AM, "Christopher
Hi there,
Below is my onValidate() method of a BeanEditForm for updating a user's
profile, where I simply check that a user isn't changing his username to
an already taken username. The error output (below it) suggests that
BeanEditForm is committing the change to the database even before
14 matches
Mail list logo
