Although I've been using Eclipselink JPA for over a year now, I'm still little more than a neophyte.
Last year I replaced our 14 year-old, home-grown ORM layer with JPA. We had a legacy feature that I'd like to replicate in the JPA Entity but not clear on how to go about it.
Is is somewhat akin to "flex fields" and in other regards, not so much.
Essentially, my native query includes columns for which there are no Entity fields/mappings. What I'd like to do is have these automatically inserted into a key/value map on the Entity when the Entity is constructed from the ResultSet.
Just read the link you provided and I like the functionality however, due to the nature of this legacy feature, the metadata is unknown until the time at which the native query is executed.
The home-grown ORM just placed all ResultSet values for which there was no direct mapping into a map where the values were available for subsequent access. This was done in our equivalent to getResultList().
There's no easy solution for this because EclipseLink with caching and cloning depends on a stable mapping between object and table and knowing what fields are persisted. Do you just want to read data into POJOs or do you have to read entities?
The data really is equivalent to flex fields but reside in a relational format that doesn't lend itself easily to mapping via the standard JPA approaches.
Since it's legacy and there's a lot of old code leaning on it, don't want to touch it. That's why it was easiest with the old ORM to simply place these columns from the ResultSet in a Map.
In the last 24 hours, I've devoured the documentation - read up on Dynamic and Extensible entities for which neither are a good fit. I stumbled upon the query redirector and toyed with same but quickly discovered that it really didn't facilitate access to a builder where I'd have iterative access to both ReslultSet and the constructed Entity.
Oh, and I failed to address one of your questions: I don't want to persist these values from the Entity. They're transient and read-only.
In the last year, this is the first and only show-stopper I've encountered augmenting functionality from the old, home-grown ORM with JPA. To say that Eclipselink is very robust and feature-rich would be a gross understatement.
I think you're going down the paths I would explore. Marking the query results as read only and maybe even setting the cache retrieve mode to BYPASS should avoid the cloning issue. One possible approach is to look at a postBuild DescriptorEventListener that you would configure in a Customizer. Subclass DescriptorEventAdaptor and just override the postBuild. Through the passed DescriptorEvent parameter you should have access to the read row (Record). At this point you could examine the Descriptor to figure out what read columns are mapped and which ones you need to put into your Map. FYI, you can attach properties to Descriptors so you could cache this information so you don't have to calculate it every time.
I'd assume it's because EclipseLink has no knowledge of the column names because they aren't mapped to fields. With native SQL queries, the SQL is passed directly to the database and isn't parsed by EclipseLink. What are the keys in the Record for the unmapped columns?