You got to be joking, right? Every "real life" programmer knows that, there are many existing database use different combination of char or string on a table boolean field, such as "True/False", "T/F", "Yes/No", "Y/N", "-1/0", and etc. Thus, as a "real life" programmer, I kind expect the JPA should allows me specific a boolean field via Annotation, such as example below:
@booleanField(trueValue="Yes", falseValue="No")
private Boolean enabled;
And to my surprise, the answer is nope!!!..So far only Hibernate JPA provider provide data type conversation. Daniel Pfeifer, have explain the problem in details, he also discuss some solutions to work around this stupid limitation at his blog, title "Type Conversation with JPA", do check it out.
Daniel's "manual mapping" idea, do solve the limitation. However, maybe it's just me, I just don't like the idea to temporary change a Boolean field to map with database data type (either char, string) in order to resolve the limitation, even we make the field private, this is just me. And I am stubborn, and old . :-)
Anywhere, after some research (Also, a good excuse to my manager to research how difficult to come out our own custom Java 5 annotation with custom Java APT process factory), I come out our own compile time annotation, called @BooleanMagic with our own BooleanMagicProcessorFactory, which I hope, shall temporary resolve the problem.
@BooleanMagic comprise of three attributes:
- trueValue, specified the table boolean field true value here, such as "True", "T", "Yes"
- falseValue, specified the table boolean field false value here, such as "False", "F","N"
- columnName, tableColumn name;
Thus, as an example, assuming we have a boolean field called "enabled", which map to table "ENABLED" field, with boolean value of "True"/"false", we will specified our VO as below:
@Entity
public class SomeVO {
@Id
Integer id;
@BooleanMagic(trueValue="True", falseValue="false", columnName="ENABLED")
private transient Boolean enabled;
public Boolean isEnabled() {
return enabled;
}
public void setEnabled(Boolean enabled) {
this.enabled = enabled;
}
}
Using Java "APT" tool with JPABooleanMagicConverter factory, code above will be converted to:
@Entity
public class SomeVO {
@Id
Integer id;
private transient Boolean enabled;
//---
//--- Lines below are generated by JBPCC BooleanMagicConvertor PROCESSOR
//--- START :
@Column(name="ENABLED")
private String magicBooleanEnabled;
public Boolean isEnabled() {
return this.magicBooleanEnabled.equals("True") ? Boolean.TRUE : Boolean.FALSE;
}
public Boolean getEnabled() {
return this.magicBooleanEnabled.equals("True") ? Boolean.TRUE : Boolean.FALSE;
}
public void setEnabled(Boolean trueFlag) {
this.magicBooleanEnabled = trueFlag ? "True" : "false";
}
//--- END
//--- GENERATED BY JBPCC BooleanMagicConvertor PROCESSOR
}
Now, isn't that cool (haha, sorry, I am bit biased here). Btw, BooleanMagicConvertor is portable across JPA protable, and IMHO, this is a better interim solution till JPA make data conversation standard.
I decided to contribute my BooleanMagicConverter back to open source community, it's currently park under my open source project Java Batch Process Control Center, at http://code.google.com/p/jbpcc, you could either build from the source, or get the "BooleanMagicProcessorFactory.jar" from here.
Here an example of how to use the BooleanMagicConvertor using Ant 1.7 apt tasks, assuming all your entity class is declare at ${src.dir}/org/abc/domain/model directory, and you wants to output all generated call to ${basedir}/target directory
<target name="preProcessJPABoolean" depends="buildJPABoolenProcessorFactory">
<apt srcdir="${src.dir}/org/abc/domain/model"
destdir="${build.classes.dir}"
classpath="./dist/BooleanMagicProcessorFactory.jar:./lib/Model_Dependent_thirdparty.jar"
debug="on"
compile="false"
factory="org.jbpcc.util.jpa.BooleanMagicProcessorFactory"
preprocessdir="${basedir}/target">
</apt>
</target>
That's all, do share me your thoughts and comments, cheers!
11 comments:
Great workaround.
And I agree, "manual mapping" isn't very nice, but for the moment it's either exposing the Persistence Provider's functionality (creating non-portable code), writing the code myself and, obviously, your converter (I am sure someone else will find yet another neat solution :D)
After quickly reviewing it, it however leaves me wondering: Will this work when one is using Maven to build? I guess it should since Maven can execute ANT tasks. Have you tried it?
Very interesting post. My name is James - Zone Leader at JavaLobby. I'd really like to repost this on JavaLobby - if you're interested send me a mail and we can discuss further.
James
Hi Daniel and James
I haven't try it on Maven, I still prefer good old Ant with Ivy.
And James, please go ahead to post it at JavaLobby.
Cheers
Sadly, your solution has a big problem. It does not support the JPA QL. If I want to write a query using the boolean field then it won't work. I gues, the JPA 2 spec (or whatever its called) needs to add this on to their feature list.
100% agree with above.
This solution is just a knick-knack while it not support JPA QL
And i am sick and tired of plain JPA .
People - use hibernate + spring! and you will not have a problems.
openJPA has an
org.apache.openjpa.persistence.ExternalValues
and
org.apache.openjpa.persistence.Externalizer
feature.
Are you still using this approach?
And/or does Spring save the day as Leonid said? If so, it is not immediately obvious to me how Spring helps solve mapping Boolean to Y/N.
So spring doesn't but hibernate do ;)
And spring makes development easy.
Spring doesn't but hibernate do ;)
And spring - makes development easy.
Could you answer how hibernate can help us?
I've been searching this for some time and the only think I founded is hibernate.query.substitutions, but I don't think it's the correct approuch.
Post a Comment