It sounds like a bug. If something is not insertable, then I would
expect that you'd get an exception at commit time. That said, I do
seem to remember some incredible discussions on the expert group about
how changes to such fields could be simply ignored by an
implementation, which also sounds like a bug.
So I guess I'm not sure what the spec requires of non-insertable and
non-updatable fields.
-Patrick
On Apr 28, 2008, at 11:07 AM, David Wisneski wrote:
Behavior of retrieving an entity is different when retrieving from the
DataCache vs. Database. An example scenario:
persist new entity with field1=1, field2=2, field3=3
field 2 and field 3 are mapped to column 2 and field3 is marked as
insertable=false, updateable=false.
If the entity is fetched from the database, the values of field1,2,3
are (1,2,2). However if the data comes from the DataCache the values
are (1,2,3).
The DataCache is not honoring the settings of insertable, updateable
when copying data from the Entity to the CacheEntry.
Is this behavior working as designed or a bug?
A similar remark applies to FetchPlan and DataCache. If an entity
field is marked EAGER, and the data is fetched from DataCache, if an
EAGER field has not data, then no database fetch is triggered.
So a retrieve from DataCache seems to be giving whatever data is in
the CacheEntry and is not honoring eager fields.
Is this working as designed or a bug?
The OpenJPA manual does not document how insertable, updateable, eager
work regarding DataCache. From a practical point of view,
DataCache should not change the semantics of EntityManager operations.
So these behaviors might be classified as bugs.
Do others agree ?
--
Patrick Linskey
202 669 5907