1

I can't solve this problem.
Can anyone tell me it it is possible to solve it?

I have a five-table database that requires 5 persistent classes.

All 5 need to carry these 3 String fields:
field1, field2, field3.

HOWEVER. Each of the 5 persistent classes makes different different combinations of them persistent with the others @transient. Here are the five persistent classes:

    Persistent         @Trasient
1   field1, field2     field3
2.  all 3              none
3.  field2             field1, field3
3.  none               all 3
4.  field1, field3     field 2
5.  field 1            field2, field3

I'd love to super class the get/set methods.

(There is a lot of code used to test them before accepting them that is identical.)

Is it possible?

I think the answer is NO. But I thought I'd check.

Thanks.

Costi Ciudatu
  • 37,042
  • 7
  • 56
  • 92
George
  • 509
  • 2
  • 9
  • 25
  • I think a real life example would be more useful to understand what you're trying to solve. – Costi Ciudatu Apr 12 '16 at 21:48
  • Inheritance for the sake of data sounds terrible. If you don't want to have the boiler plating of getters and setters, you could take a look at [project lombok](https://projectlombok.org/). – Jorn Vernee Apr 12 '16 at 21:49
  • Specific example: My database has five tables that store an id, pw and a hash for various reasons. One table has all 3 fields. Other tables have fields for 1 or 2, but not all of them. But for other reasons, I'd like all three POJO classes I use as entities to carry all three as variables. So a commen parent is attractive. – George Apr 14 '16 at 20:32

1 Answers1

0

This seems to be one of the use-cases that are not suitable for annotation metadata.

JPA allows you to override, supplement or replace annotations with XML metadata. In a scenario like you described, I think it would be best to define the persistent/transient fields in XML metadata.

You may want to check the hibernate docs or this closed StackOverflow question for more details.

Community
  • 1
  • 1
Costi Ciudatu
  • 37,042
  • 7
  • 56
  • 92
  • Thanks. The answer seems to be no I can't. So adding a get/set for each of the three variables to every class I use as an entity seems easier than messing about in XML metadata. – George Apr 14 '16 at 20:35
  • You can still have a base class containing the three variables plus getters and setters (say, all `@Transient`). And in your subclasses, you will only overwrite the getters for what you want to persist and simply call `super.getField()` in the implementation. I think this is the closest you can get to what you want. But you don't have to fear XML, as it allows you to actually keep a single Java class and map it multiple times with various options. – Costi Ciudatu Apr 14 '16 at 21:18
  • To further address your disappointment, think of it like this: annotations are metadata that stays with the code, as long as they map naturally. If they don't (like in this particular case) you have to either *write the code so that it can be annotated* **OR** *move the metadata outside the code* (into whatever external format is available). I would always choose the latter. If you'll ever decide not to use JPA anymore in your project, you'll end up with a pile of nonsense classes that only used to serve as a place to put annotations in. So "messing about in in XML metadata" may be worth it. – Costi Ciudatu Apr 14 '16 at 21:52
  • Thanks again. I often try, but both Jboss and Oracle documentation writers seem personally offended that anyone who doesn't already know the answer would read their material. Here's hoping either one someday decides to hire people who are good at documentation. But for now what I've found is their material is only useful for people who don't need it. It's like asking how to drive a car, and getting a lecture the 7 different ways you can change the radio station while driving. Impressive additional info ... but only after you know how to get it moving. – George Apr 15 '16 at 22:42
  • I forgot to mention using super was ... well .. a super idea in my case where there is a lot of code in the setters. Wish I had thought of it first. And it confirms I can overwrite a non-persitent parent field with a persistant field in the child. Something that seemed obvious to you to begin with, but for me just became obvious. Thanks again. – George Apr 15 '16 at 23:24