Fix#2 — @DtoRef never checked hasField(): Added requires() to @DtoRef
(same explicit-empty semantics as @DtoPath). DtoMappingReader now
detects a computed association getter and requires an explicit
requires(); DtoMapperWriter's REF case routes computed segments
through extraFetchPaths instead of a broken select(assoc).
Fix#3 — requires() values never validated: Added DtoMappingReader.validateRequiresPath(...), walking every requires() segment against the real property graph (with List unwrapping via a new getterReturnTypeMirror helper). A typo now fails at compile time instead of resurfacing as a runtime PersistenceException. New negative
Fix#4 — bare requires() fetch vs narrowed sibling @DtoPath fetch collision: Traced into Ebean's OrmQueryDetail.fetch(...) and confirmed same-path fetch calls replace, not merge (Map.put). The old dedup logic had priority backwards, silently letting a narrow selection win and drop a computed getter's real dependency. Fixed by prioritizing the full fetch. Proved the regression test was meaningful by reverting the fix and confirming it fails with LazyInitialisationException: Property not loaded: line1, then restored the fix and confirmed it passes.
* Version 18.3.0
* InsertOnConflict - change to exclude non-updatable and generated on insert only (e.g. @WhenCreated)
---------
Co-authored-by: robin.bygrave <robin.bygrave@eroad.com>
* #2540 Add DTO mapping from Entity beans via generated mapper code
A large feature, refer to the docs / guides etc. This is a bit like MapStruct in that it generates mapping code via annotation processing but it ALSO creates an optimised FetchGroup for the destination DTO graph and it also implements a generic interface such that it can be fluently used via query.mapTo().
The value is that it automates the mapping code from entity -> dto plus optimises the query used to support building the DTO graph.
Expected to be better to use than MapStruct for ebean orm users.
* Bump ebean-annotation to 8.6 with the dto annotations
* Adjust the build order to via test dependency on ebean-api
---------
Co-authored-by: robin.bygrave <robin.bygrave@eroad.com>
* creates support for generics in mapped superclasses
* Changes DeployCreateProperties to allow processing of inheritance hierarchies with generics
* adds tests for ebean-querybean
* bumps querybean-generator version
* fixes tests by changing table names for ProductWithGenericLong and ProductWithGenericString
* Restore format, this reduces the diff
* Restore format, this reduces the diff
---------
Co-authored-by: Rob Bygrave <robin.bygrave@gmail.com>
warning: No processor claimed any of these annotations: /io.ebean.typequery.TypeQueryBean,/io.ebean.typequery.Generated
This fix is required when the compiler is run with -Werror specified
An alternative workaround is to use compiler arg -Xlint:-processing rather than -Xlint:all
@MappedSuperclass was excluded from the generated reflect-config.json, this PR fixes that.
The missing reflect-config entry for MappedSuperclass means that with native-image the @Id property isn't found when its on a MappedSuperclass, and that ended up as a NPE in BeanPropertyAssocOne.
Die to Quarkus dev mode (#3541#3582) we want to log FilerException at WARN level rather than ERROR. This is because Quarkus dev mode will invoke the annotation processor more than usual, so we expect to fail with the FilerException.
Rob Bygrave