We're updating the issue view to help you get more done. 

Remove persist() on Session API

Description

This is from a user/documentatio perspective, completely ignoring any reason on the implementation side. Stay with me.

The persist() operation on Session is not cascaded at flush time. This is somewhat unexpected from a users point of view and very difficult to explain and understand (you need excellent knowledge of flushing and cascading). Reason #1 for removal.

The persist() operation in general does not return a database identifier. This is surprising, as the JPA spec clearly requires a persistent instance to have a database identifier value. Since persist() makes instances persistent, it has to have the same semantics for assigning identifiers as save(). Hence, I expect that once this mismatch is resolved in the expert group, the persist() method will return a database identifier. Everything else doesn't make much sense, given the current specification and documentation. Conclusion is that persist() will have the same signature as save(). Reason #2 for removal.

To document persist() properly I need a reason for its existence. Right now I'm telling readers/users to ignore it on the Session API, because it only complicates the situation with no benefit.

Environment

None

Status

Assignee

Unassigned

Reporter

Christian Bauer

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Priority

Major