Interesting -
I though if field 3 is marked as updatable and insertable to false was only
for the DB operation.
Therefore in your sample it seems that you set field 3 to 3 and then put it
into the cache.
I would actually hope that when you get the data back that field 3 would be
3 again and not 2.
I could see this being important if someone loads data from the DB - you
first start with field 3 = 2 (from DB).
Then you would chnage its value to 3 for whatever reason and save the data
- then the DB field 3 should be 2(updatable = false) but the value in the
cache should be 3. Otherwise this state information field would become
useless since it will be lost everytime.
I would have thought that it is the dev responsibility to invalidate/remove
this data from the cache if they dont want to keep the state of field 3 to
3.
Maybe I am thinking about it wrong. I can also see the otehr argument about
the cache not changing the behavior. But becuase of the (updateable=false)
setting - it seems to me that doing that should mean - "It is OK for the
cache to be different than the DB". That is how I understand
updateable=false.
PS: Of course one could/should use transient field instead to put its state
that should be kept in the cache but not the DB.
Patrick Linskey
<[EMAIL PROTECTED]
om> To
[email protected]
cc
04/28/2008 01:30
PM Subject
Re: datacache behavior fetchPlan,
insertable, updateable
Please respond to
[EMAIL PROTECTED]
e.org
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
