openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: datacache behavior fetchPlan, insertable, updateable
Date Thu, 01 May 2008 17:06:49 GMT
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

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

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                                               
             om>                                                        To 
             04/28/2008 01:30                                              
             PM                                                    Subject 
                                       Re: datacache behavior fetchPlan,   
                                       insertable, updateable              
             Please respond to                                             

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.


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

View raw message