Ok - our code has a default finder used generically for all calls, though
some locators override it. I hadn't been very aware of it - it was this
that was causing the issue.
Once I overrode the finder to fill in transient values, my problems went
away.
Thanks for pointing me in the right
Ah, ok - I didn't realize that I was able to provide my own modification of
the locator method. In my debugging of our code, I saw the RF framework do
a direct to an EntityManager.find() method. For some reason I didn't see
that this was something we could modify. I also wasn't aware of
> But when RF looks up the current value to compare, it will always be null
> because the regular lookup doesn't set the transient value.
>
RF expects a correctly filled entity after loading it from the DB using the
entity locator methods (because RF only sends changed data). It's your job
... or maybe an improvement, whereby fields marked @Transient would always
be sent, and not use the usual lookup/compare workflow?
I'm surprised it works the way it does - when the original value is
fetched, we set the @Transient values when returned to the client. But
when RF looks up the
Sorry, yes, it was an EntityProxy.
My ideas to solve it were:
1) Use a ValueProxy instead of an EntityProxy
2) Use a ValueProxy for the @Transient String value (dunno how a transient
value, expressed as a ValueProxy within an EntityProxy, would be handled,
or if it's allowed)
3) Pass the
Assuming an EntityProxy here, if the field is left unchanged, then it's not
sent to the server. On the server side, the entity is loaded by the Locator and
then the diff is applied. So if the Locator gets a null field, it'll be left
null.
You may have to use a ValueProxy here…
--
You received
Hi all...
So I have a situation where we have an entity persisted with JPA on the
server:
public class MyEntity ... {
> private String field1;
> private String field2;
> @Transient
> private String myTransientField;
> }
... and we have a proxy:
public class MyEntityProxy ...
