Re: JPA+hibernate merge vs find fetching lazy collection
Tom Anderson wrote:
Lew wrote:
Puzzle 1: Why are you explicitly allocating an ArrayList to
'objectsCfgSet'?
kamiseq wrote:
why not? and plus you dont need to check every time if collection is
null or not. this is not a problem here
Lew wrote:
Why not? Because it's atypical of JPA code and I haven't seen that
done. Usually you either let the JPA engine fill it
Tom Anderson wrote:
Which won't happen before the JPA provider has got its hands on it, so:
new GenObject().objectsCfgSet.add(something);
Will fail, right?
Well, duhh. You're supposed to pass in the List, not depend on it being
there. That's why there's a setter for it.
And it will certainly fail if 'objectsCfgSet' were properly declared as 'private'.
They're using setters because they're using property access - note the
@Id annotation on the getCustomerID() method rather than the id field.
That means they have to use setters to set fields. Kamiseq is using
field access, which means he can access the fields directly. There's no
JPA-specific reason for him to use a setter rather than direct access.
There is a common idiom, universal to all the training literature on JPA, to
have setters for even the collections. Furthermore, when you set up
field-level annotations you still have bean patterns for the properties, and
the variables remain 'private'. Your point does not apply.
It's not that I think that initialization was wrong, necessarily. As I
stated, it's atypical. Not one bit of training literature that I've read has
done that, and not one bit of the JPA code I've worked with has, either. So
it looked odd, and I wondered why he did it. A perfectly reasonable question,
when you encounter an idiom that none of the experts use.
Now I'm wondering why the OP took the question as an attack instead of a
request for information.
Anyway, once you persist the object, the initially-allocated List goes away
and you lose control of whether it's null. So the point of not having to
check if the collection is null doesn't apply, either.
I think it's best to stick with the way JPA was designed, and I infer from the
universal absence of collection initialization in the training literature that
it was designed not to need it. I've seen what can happen to ORM code when it
deviates from the intended idioms. You introduce epicycles that get ever more
rococo. Entity objects are not really meant for a lot of manipulation outside
the JPA context or by application logic. The more complicated you get with
them, the weirder the behaviors you start to observe.
I recommend not initializing the @OneToMany and @ManyToMany collections, but
simply letting JPA do its job.
As a rule.
--
Lew