Re: Persistence API - magic?
markspace wrote:
nroberts wrote:
It must be the field names because I just tried to change one but left
the getter/setter alone. It exploded with a pile of exception vomit.
"Exception vomit" is vague and hard for us to diagnose. You could have acc=
essors that refer to the old field names, but that would be "compiler vomit=
", not "exception vomit", assuming I understand your vague and unconvention=
al term correctly. You might have mixed annotations for fields with annota=
tions for accessors, which doesn't work in the JPA implementations I've use=
d. You might have mismatched attribute names and column names. "Exception=
vomit" just doesn't tell us anything useful. I guess that makes the post =
"Usenet vomit".
Actually, when I said "or," I meant that literally. Field names:
@Entity
public class Employee {
@Id
int id;
...
@Entity
@Access( AccessType.FIELD )
public class Employee { ...
Properties:
@Entity
public class Employee {
int id;
@Id
public int getId();
public void setId( int id );
...
}
@Entity
@Acces( AccessType.FIELD )
public class Employee {
@Id
int id;
@Access( AccessType.PROPERTY )
@Column( name="PHONE" )
protected String getPhoneForDb() {...}
protected void setPhoneForDb( String phone ) {...}
...
}
The last one is actually mixed and uses both fields and
accessors/mutators (properties).
Does that work for you? I seem to remember getting error messages when I t=
ried to mix field and accessor JPA annotations in the same class.
Even if allowed, it's not a good practice.
I have settled on accessor annotation. From a public standpoint, the acces=
sors define the attributes.
The country bit also blows up when you change the variable name.
Eclipse error specifically said, "join column kalifornia_id can not be
found." The auto-name recognition thing must append _id to your
variable when you do a join.
If your column names don't match the automagical defaults, you need to spec=
ify them in your annotations.
Read the JPA documentation for the details on the naming conventions.
My implementation extends the DTO classes you define and adds methods
and such to them. It might be referring to a field or property it added=
to your base class.
I don't think I like the idea of relying on this behavior.
That's why there's overrides in the form of @Column(name=) and @Table(n=
ame=)
+1
But OP, don't whine that the documentation is too hard. Understand the doc=
umentation. It tells you what you need to know, including what the default=
mappings are and how to override them.
You can't complain that you don't know how to do something and that you don=
't feel like reading the docs. You must read the docs and learn how to do =
what you want. So the docs are hard - that's why we make the big bucks. Y=
ou should have started in the days of mainframes - now *those* docs were ha=
rd to read. You have it easy - so Shut the Front Up and study. You get no=
sympathy for "The docs are too difficult! Waaaah!"
--
Lew