Re: JPA+hibernate merge vs find fetching lazy collection
On Wed, 30 Dec 2009, Lew wrote:
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.
'Duhh'? 'Supposed'? I don't know about you, Lew, but i quite like having
constructors that create objects that are in a usable state, not ones
which i then have to run round initialising before i can use them.
And it will certainly fail if 'objectsCfgSet' were properly declared as
'private'.
Of course. But you and i both understand that that's not the point we're
discussing.
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.
It's an idiom that's common throughout all java development, in fact. That
doesn't mean it's a good one.
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.
What? My point is that you're using property access, you *must* use
setters to set fields, and that if you're using field access, you *can*
use direct assignments. Apologies if i didn't make my point clearly, but
it *does* 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.
That looks dangerously like an argument from authority to me, which as you
well know is a logical fallacy. Anyway, if the code you've seen has
setters for all its persistent properties, then i submit that it wasn't
written by experts - setters should be used when there's a good
domain-driven reason for them, and not otherwise, which will very rarely
indeed mean that all properties have setters.
Still, since everyone likes a black swan, here's another post from my
favourite Dutch JPA pundit, showing that at least one expert prefers field
access and sparing use of getters and setters:
http://blog.xebia.com/2009/06/13/jpa-implementation-patterns-field-access-vs-property-access/
And an older and more general one about getters and setters:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Now I'm wondering why the OP took the question as an attack instead of a
request for information.
That, alas, i cannot help you with.
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.
Is that so? Will persisting an object ever cause a list field to be set to
null? If a list is nonexistent in the database (because there are no rows
in the join table, or no rows in the target table with a matching foreign
key), won't the JPA provider map that to an empty list in the JVM? This is
an honest question - i don't know JPA well at all.
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 already given you an example where it is needed.
I've seen what can happen to ORM code when it deviates from the intended
idioms. You introduce epicycles that get ever more rococo.
I am certainly with you in opposing epicyclicity and rocociousness. If
explicitly initialising a list led to difficulty with JPA, then i would
reconsider doing that. But only then.
Entity objects are not really meant for a lot of manipulation outside
the JPA context or by application logic.
No, no, no. JPA is a mechanism, not a policy - JPA entities are not
'meant' for anything. You might think it's a good idea to use JPA entities
that way, but it's something i'd disagree very strongly with you over -
what you're advocating is an Anemic Domain Model, and it's a bad thing
(Martin Fowler says so, so it must be true! :) ):
http://martinfowler.com/bliki/AnemicDomainModel.html
tom
--
Please! Undo clips before opening handle.