Steve Ebersole wrote:
<steve>
Sure, but all I'm talking about is the processing inside
SessionImpl.flushEntity(). If an entity is not mutable, there is a
bunch of stuff there that is not necessary between wrapping collections
and performing the FlushVisitor processing. The only question would be
the semantics of a class marked to be versioned in addition to being
non-mutable, supposedly I guess to increment the version on changes to
its collections; but even here in the current code the owning entity
would not be physically updated if this were the case.
</steve>
No, there's not anymore. Check the code.
<steve>
I didn't think I implied such a thing. All I'm talking about here is
furthering the concept of further breaking down the SessionImpl into a
series of collaborators. I have not, and don't intend, to have these
shared between sessions. Breaking the various functionalities apart in
this manner just makes it easier to assemble sessions that behave
differently based on the collaborators they use.
</steve>
Fine.
-- Gavin King +61 410 534 454 +1 404 822 8349 callto://gavinking
Hibernate [EMAIL PROTECTED] http://hibernate.org
JBoss Inc [EMAIL PROTECTED] http://jboss.com
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
