rzo1 opened a new pull request, #167: URL: https://github.com/apache/openjpa/pull/167
The `@IdClass` extraction and reconstruction paths added for the JPA 2.4.1.3 example 2b case caught every exception and continued: on write the primary key columns were filled with nulls, on read the field was left null, so a corrupt identity could be persisted or loaded without a trace. Both paths now raise a `StoreException` naming the field, the id class and the mapping, with the original failure chained. A null id class value on the write path is legitimate, so it still writes nulls, but logs a warning. The columns are also no longer paired with the id class fields by `Class.getDeclaredFields()` order, which the JVM does not guarantee. Where every column names its target through `referencedColumnName` the fields are matched by that name; declaration order remains only as the fallback for mappings that provide no name, since that is all such a mapping offers. `TestDerivedIdEx2c` covers the ordering: its id class declares the fields in the order opposite to the join columns, so a `find()` misses on the previous code and succeeds now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
