• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

unique constraint

 
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I used a table that has a autonumber thru a control table. Lets call this column the pk.
I have another column userLoginName which I keep unique. Since I am not allowed to change the pk I will have the benifit of being able to change the loginName under some rare circumstances.

When I create a entity bean and the loginName already exiusts it throws a CreateException. And there is no sure way of knowing what is the cause ( unlike wityh a duplicateKeyException ) because loginname here is not a Primary key just a unique field.

The only way to handle this seems to be that I do a findXXX method first to check the unique key existence.

What do u guys thiunk? Got any sugegstions?

Is that a bad design to have a automumber pk and a unique loginName?
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Swamy,
That is a great design! You recognize that users should be able to change their login name.

Doing the findXXX is a good way of checking.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You should not rely on the receipt on a FinderException to tell you that an entity does not exist in the DB. For a CMT bean, the container might throw this exception before the DB is accessed.

You could instead not use a finder, try and create the entity in the DB and handle CreateException. The problem is that the client cannot be sure what happened as the container may throw this exception after the transaction was committed. So, on balance, I guess the least worst approach is to use the finder method.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic