Hi there,
Thanks for the reply. I am not entirely sure what you mean, but I think I do. I have always figured keeping a Collection<Long> of ids and in my named queries using those ids instead of allowing the @OneToMany to handle when to load deep data would be better. Honestly, while I love the ease of the entity beans, I sort of miss using
JDBC. I know we still can, but I am trying to utilize the EJB 3 capabilities, especially having read that many containers may implement caching and other performance tricks behind the scenes that avoid me having to come up with all that.
What is most difficult is remembering to set both sides of the relationship. For example, in the TransactionEntity, I want to be able to call getUser() to get the user that the transaction belongs to. As well, I want to be able to get all the transactions for one user, so the UserEntity getTransactions() should handle that. However, when storing a bunch of transactions.. what I am not sure of is.. do I persist each transaction, then add it to the collection on the user entity.. or can I do something like:
In other words, is it enough to simply get the UserEntity (managed object), grab the collection object of transactions, and add more to it, and that updates the new transactions (along with what was already there)? Or would I then need to call ue.setTransactions(trans); to cause the container to merge/persist the updated collection?
I thought I would have to do something like:
This example I would assume persists each transtion entity so thats its got a created generated ID.. setting the user on it for each. Then, updates the user side by adding all the trans to the UserEntity, then merges that object?
All gets confusing dealing with two sides. I just want to make sure user.getTransactions() returns the list of all, and transaction.getUser() refers to the owner user.
Thanks
.