title: JPA @OneToMany Sets and unique contstaints
body: <p>I have the following scenario:</p>
  
  <p>I have a system full of users.  There is a desire to run contests for users who log into the site over a week or so. Therefore I needed to create a new Contest object which would contain both the entries and the winners.</p>
  
  <p>I created something like this:</p>
  
  <pre><code>private Set&lt;User&gt;;
  
  @OneToMany(cascade = CascadeType.REMOVE, fetch = FetchType.LAZY) 
  @JoinTable(name="contest_entries", 
          joinColumns = {@JoinColumn(name = "contest_fk", referencedColumnName="contest_id")},
          inverseJoinColumns = {@JoinColumn(name = "user_fk", referencedColumnName="id")})   
  public Set&lt;User&gt; getEntries() {
      return entries;
  }
  </code></pre>
  
  <p>The idea being that a Contest can have multiple entries.  Seems simple.  It generates the following:</p>
  
  <pre><code>create table contest (contest_id numeric(19,0) identity not null, primary key (contest_id));
  create table contest_entries (contest_fk numeric(19,0) not null, user_fk numeric(19,0) not null, primary key (contest_fk, user_fk));
  alter table contest_entries add constraint FK7FBD0C65C4F120C2 foreign key (contest_fk) references contest;
  alter table contest_entries add constraint FK7FBD0C656ABC75E3 foreign key (user_fk) references user_profile;
  </code></pre>
  
  <p>However, once a contest is over, the desire is to run another contest.  When I attempt to create a new contest and have one of users who had entered previously enter again, I get a unique key constraint.  Looking at the table DDL, it makes sense that it does.</p>
  
  <p>So, in essence, I can't run two contests at the same time.  I would also lose history of people entering the contests.  That's not going to work.  I need to be able to run two contests at once with the same users in different contests.  </p>
  
  <p>I'm new to JPA, so I have to believe I'm missing something obvious.  The system already has a user table and it's populated full of users.  There is a desire not to change that table structure.  Any ideas on how to solve this?  If it matters, the persistence implementation is Hibernate.</p>