This content has been marked as final. Show 3 replies
I think the addition of @NonPersistent is a reasonable request and probably the only good solution. One of the primary goals of the DPL is to be able to persist objects that are used in other ways -- RMI is a good example. In other words, the DPL intends to be a pure POJO persistence solution. However, we didn't consider the case of a field that is persistent with respect to RMI but not the DPL, or vice-versa. So I think solving this is important.
Let us spend some time on that and we'll see if we can get this into a 3.3 dot release. This is a fairly simply addition, but we'll need to also consider the reverse situation -- a field that is persistent WRT the DPL but not RMI. In other words, we may need both @Persistent and @NonPersistent to apply to a field to override the default rules. And we'll need to encapsulate this information in the EntityModel abstraction so that it can be used without annotations.
In the meantime, I suggest using one of the workarounds you mentioned, or perhaps even modifying the DPL source code in a way that works for you, temporarily.. If you choose the latter, note that there is only one place where field persistence is determined, which is in the getInstanceFields method of this class:
See the call to Modifier.isTransient.
Thanks for the response. For the time being, I've modified writeObject and readObject to include the data that I want. This seems to work reasonable well. I'll be very happy to change it to use an @NonPersistent annotation if it works out. And you're absolutely right -- somebody might want to persist a transient member (although I would suspect that this is the less frequent case).