Issue #71: new objects not available in mappedBy associations

Given a mappedBy association: e.g:

@OneToMany(mappedBy="department") public List <Employee> employees;

creating a new mapped class, e.g. new Employee, won't result in this object being available in the same transaction:

ie:

for (Employee e : department.employee)

won't include the new object, even if it is persisted, and even if the transaction is committed??

This seems to be the normal behavior - according to JPA the application has to update both sides in order to have a synchronized bi-directional relationship.

In practice, however, the mapped side will be updated automatically when the object is retrieved from the database again.

Try to refresh the department object after the transaction is committed (or after the update and before commit, if your EntityManager is set to use FlushModeType.AUTO).

What does this mean: "Try to refresh the department object" ?

How does one refresh an object?

If the mappedby tag maps to:

SELECT e from EMPLOYEE e WHERE e.department=department

then shouldn't it automatically return a newly created Employee object if that object's department is set?

I'm wondering if I'm doing something wrong, but I'm definitely seeing that, in general, newly created objects are not immediately available in collection queries. I'll try to find a 'real' example, and I'll also examine the FlushModeType.AUTO option as suggested.

> What does this mean: "Try to refresh the department object" ?

> How does one refresh an object?

https://www.objectdb.com/java/jpa/persistence/retrieve#Retrieval_by_Refresh

> If the mappedby tag maps to:

> SELECT e from EMPLOYEE e WHERE e.department=department

> then shouldn't it automatically return a newly created Employee object if that object's department is set?

Yes, but if the query has already been run and the field already contains a value - it will not be run again unless the object is retrieved again from the database (and not from the persistence context cache), or refresh is invoked.

Hmm, I see, so if I excute a query and then create an object that belongs to that set, then call the query again, I won't get the object back? That's pretty much what I'm seeing, but not what I expect at all, I was expecting that the object would be returned in the second query.

Do I need to call refresh() on the object, query, or EntityManager?

ps: setting FlushModeType.AUTO in the EntityManager resulted in a huge exception message.

> Hmm, I see, so if I excute a query and then create an object that belongs to that set, then call the query again, I won't get the object back? That's pretty much what I'm seeing, but not what I expect at all, I was expecting that the object would be returned in the second query.

That doesn't happen with ordinary queries. Only with automatic queries that are used for inverse fields, after the inverse field has already been initialized.

> Do I need to call refresh() on the object, query, or EntityManager?

The argument to refresh is the object that contains the inverse field. This way you enforce reloading the object and running the automatic query of the inverse field in that object again.

> ps: setting FlushModeType.AUTO in the EntityManager resulted in a huge exception message.

Please post it (or send it by email).

> That doesn't happen with ordinary queries.

> Only with automatic queries that are used for inverse fields, after the inverse field has already been initialized.

yep, that's what I saw.

I'm going to test calling refresh() on the owning side.