JDO @unique constraint

Showing 1-10 of 10 messages
JDO @unique constraint johnfromCalgary 6/19/09 11:00 AM
I'm using this :
private String activity;

in a class definition,  but "pm.makePersistent(activity);" will create
a new record with the same value.

I'm getting around it by reading all the values into a hashtable and
checking for uniqueness before calling makePersistent, but I'd like to
know what I'm doing wrong.

is that syntax for @unique correct? I can't find any other posts that
mention this so I assume I'm just making a silly mistake.

Re: [appengine-java] JDO @unique constraint keakon 6/19/09 11:08 AM
It's no affect with @unique.

Only key can be unique.

2009/6/20 johnfromCalgary <jdp...@gmail.com>

Re: JDO @unique constraint johnfromCalgary 6/19/09 11:30 AM
It has no effect because JDO doesn't support it, or because the google
app engine doesn't support that part of JDO?
There must be a way to have more than one unique field in an object.
If @unique isn't the way to do it, what is?


On Jun 19, 12:08 pm, 风笑雪 <kea...@gmail.com> wrote:
> It's no affect with @unique.
> Only key can be unique.
> 2009/6/20 johnfromCalgary <jdpo...@gmail.com>
Re: JDO @unique constraint datanucleus 6/19/09 11:38 AM
Why not read the issue tracker ?

JDO itself defines support for all such things.
Re: JDO @unique constraint johnfromCalgary 6/19/09 12:21 PM
Thanks for the link. The getting started pages didn't seem that clear
about the differences between "JDO" and datanucleus-appengine's
version of JDO.

Okay, so that feature of JDO isn't supported, is there a "best" method
to handle this outside of JDO?

I'm using a HashSet to read in all the existing values and then check
for uniqueness. It means less calls to the persistenceManager, but
it's an ugly hack.

On Jun 19, 12:38 pm, datanucleus <andy_jeffer...@yahoo.com> wrote:
> Why not read the issue tracker ?http://code.google.com/p/datanucleus-appengine/issues/detail?id=22&co...
Re: JDO @unique constraint bcottam 6/20/09 9:26 AM
I've run into this in my app.  What I currently do, is before saving
my bean, I perform a query to select any entities that have a property
with that value (i.e. I select only those entities that share the
value I want to be unique rather than iterating over all instances).

like this:

public class MyBean {

// @Unique -- unique annotation not supported
private String myUniqueString;

then, in the class that persists MyBean:

public MyBean save(MyBean bean) {
     Query q = pm.newQuery(MyBean.class, "myUniqueString
= :stringValue");
  ..... set parameters on q.....
  .... get list of results (should be small)....
  .... iterate over list and make sure that either no beans other than
the one I am saving has the same value for myUniqueString....
  if (!unique) {
      throw new IllegalStateException("MyBean.myUniqueString must be
unique: " + myBean.getMyUniqueString);

pardon the pseudo code :)
The main difference is that I am hopefully selecting fewer entities
from the datastore to iterate over.  If no other entities have the
value I am trying to save, I'll get none back, if only the result I am
saving has the value I am trying to save, I'll only get it back, if
some other entity has the same value, I'll get it, detect that it's
not the same entity I am saving and I simply throw some kind of
exception that I can consume and report to the user.
hope that helps
Re: JDO @unique constraint johnfromCalgary 6/20/09 10:11 AM

Thanks. That method is cleaner than mine. If I use that for single
record inserts, and then a "select all" for large list inserts, it
should do the trick.

Re: [appengine-java] Re: JDO @unique constraint keakon 6/20/09 1:53 PM
GAE doesn't support it both in Python and Java, not only JDO.

2009/6/21 johnfromCalgary <jdp...@gmail.com>

Re: JDO @unique constraint idueppe 6/21/09 3:36 AM
I'm not sure but are you sure that this really works in a
transactional environment?
I mean if after your unique verification end before commit another
transaction commits the same record this will end up in duplicated
Re: JDO @unique constraint bcottam 6/21/09 9:50 PM
yeah, keeping the transaction in mind is certainly important.  As I
understand it, you can read whatever you want in a transaction,
however only one entity group can be saved in a single transaction.
In fact, you could read from one PersistenceManager, and save with
another.  I don't know of a way to "lock" an entity type (you can't
lock a table, 'cause all entities in BigTable are in the same table)
so someone else could be saving an entity with a "duplicate" value in
another thread/transaction, and the approaches discussed here don't do
anything to defend against that, but it's better than nothing  :)
Anyone know of a better way, I'd love to hear about it, but this is
about the best I could come up with.