views:

282

answers:

2

I'm working with DataNucleus as part of a Google App Engine project and I'm having a bit of trouble with columns in persistence.

@PrimaryKey(column = "user_id")
@Column(name = "user_id")
@Persistent(name = "user_id", column = "user_id", valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key m_id;

@Column(name = "user_name")
@Persistent(name = "user_name", column = "user_name")
private String m_userName;

If you can't tell, I'm trying to name the column something different than the name of the variable because I have two naming conventions (one works better in Java, one works better in SQL). Anyway, I've tried all variations of those marker annotations but the DataNucleus enhancer refuses to honor any of them, so when I run a query like this:

Query q = pm.newQuery(User.class,
                      "user_name == _username");

I always get an error like this:

org.datanucleus.store.appengine.FatalNucleusUserException: Unexpected expression type while parsing query. Are you certain that a field named user_name exists on your object?

Of course, when a run a query like this:

Query q = pm.newQuery(User.class,
                      "m_userName == _username");

...everything just works great. So, there would be a field named user_name if any of those annotations were honored, but they're clearly not.

SO my question is: Is there any way to decouple the tokens I use in the query from the name of the field? I'm looking for the ability to change the names of the fields without having to edit the queries by hand.

NOTE: I would sooner just use my SQL naming conventions in the Java classes than write the hideous amounts of XML by hand, so this has to be done with the annotations.

+1  A: 

Not 100% sure I get what is your problem. If you use m_userName in your query does it get translated as user_name in the SQL query?

You express you query according to the java class names and variables and they get translated to work according to the the SQL schema table and column names. That's most of the time what people want.

BTW, m_id and m_userName is a terrible naming convention for Java code. I would strongly advise you to follow the usual convention.

ewernli
Ah, I see...so I've misunderstood what the annotations actually do. The actual backing columns are named with the annotations while I still query with the names of the private members. Doesn't that kind of break encapsulation? I mean, now I'm not free to change the names of my variables without searching through all the string queries and altering them by hand. Is there any way to isolate the word I use in the query from the name of the private member?And sorry, I'm not switching from the `m_` convention, I detest the `this.` gobbledygook.
Travis Gockel
I guess you can annotate getter and setter instead of fields. Still, if then you rename the getter and setter, this can have a profound impact on the code (not only the query). Refactoring tools can help to change all location where a method is referenced in a consistent manner, including in strings.
ewernli
+2  A: 

No idea of the talk of SQL, you're using GAE/J hence BigTable and not an RDBMS so SQL just won't work. @Column likely does nothing since it is for ORM. Here you're using JDOQLas the query language, so you use field names ... since it is an Object-Oriented query language. This is NOT SQL. You detest "this" ? JDOQL uses Java syntax, hence "this" makes lots of sense.

If you really want to have a type-safe query extension that allows refactoring then QueryDSL provides JDOQL for use with DataNucleus.

PS The DataNucleus enhancer has nothing to do with column names. It simply adds on extra methods for detecting updates to fields, as per the JDO spec.

DataNucleus
Here is the homepage for Querydsl : http://source.mysema.com/display/querydsl/Querydsl
Timo Westkämper