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 =
crudServiceDAO.findUniqueWithNamedQuery...".

As a second test, I changed the user name of James to a name not already
taken: Charlie.  No exception is thrown, but recorded in the log file is
the output of "LOG.debug("Verify user...)", namely: Verify user:
[Charlie|James|Cook].

crudServiceDAO should be returning no user by this user name, as we are at
this stage still inside onValidateFromUpdateForm.

All quite puzzling.  :-)

Regards,

Chris.


> 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 method appropriately? (For
> Hibernate entities it is officially recommended not to rely on the PK ID
> in
> your equals and hashmap methods but instead base them on the closest thing
> to a natural key or keys in each entity.)
> 3. Since you are just trying to ensure that a user isn't trying to reuse
> an
> existing user name, why not directly compare the user name strings instead
> of comparing the User objects?
>
>
> On Jan 13, 2018 4:01 AM, "Christopher Dodunski" <
> chrisfromtapes...@christopher.net.nz> wrote:
>
> 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
> page's onValidate method attempts to instantiate a user 'userVerif' using
> the new user name entered into the form: 'Abel'.  If instantiating
> userVerif is successful (someone has this user name), and userVerif is a
> different user (if both users are the same it simply means the form was
> submitted without an altered user name field), it means that this user
> name is already taken, so onValidate() records an error.
>
> If no error is recorded, onSuccess() is then fired, and this is where the
> updated user is finally committed to database:
> "crudServiceDAO.update(user)".  At least this is my intention.
>
> What actually happens in the above test scenario is that the user object
> loaded into the BeanEditForm, on hitting the submit button, becomes...
>
> User name: Abel
> First name: James
> Last name: Cook
>
> So far so good, because this is still within onValidate(), not onSuccess()
> where the user instance is committed using "crudServiceDAO.update(user)".
> But seemingly when the line...
>
> User userVerif = crudServiceDAO.findUniqueWithNamedQuery(User.BY_USERNAME,
> QueryParameters.with("userName", user.getUserName()).parameters());
>
> is reached, the exception below occurs...
>
> 13-01-2018 20:57:10 DEBUG UpdateUser:74 - [ENTER]
> onValidateFromUpdateForm()
> 13-01-2018 20:57:10 DEBUG UpdateUser:177 - onValidateFromUpdateForm
> 13-01-2018 20:57:10 DEBUG UpdateUser:179 - Form user: [Abel|James|Cook]
> 13-01-2018 20:57:11 WARN  SqlExceptionHelper:145 - SQL Error: 1062,
> SQLState: 23000
> 13-01-2018 20:57:11 ERROR SqlExceptionHelper:147 - Duplicate entry 'Abel'
> for key 'UK_h029unq4qgmbvesub83df4vok'
> 13-01-2018 20:57:11 DEBUG UpdateUser:165 - [ FAIL]
> onValidateFromUpdateForm --
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.ConstraintViolationException: could not execute
> statement
>
> I'm confused by the "Duplicate entry 'Abel'" exception, as at this stage
> there ought only be one 'Abel' in the database.
>
> If onSuccess() attempted "crudServiceDAO.update(user)" with a user also
> having userName=Abel, then naturally I would be expecting to see this
> exception error.  But this is not the case.
>
> Regards,
>
> Chris.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to