@Rob
Something like
var c = QChild.alias();
List<Parent> parents = new QChild().select(c.parent).where().c.parent.id.eq(1).findSingleAttributeList()
might be an option?
Otherwise Query Beans might need something similar to asDto() but not as "detached". Something like
var c = QChild.alias();
List<Parent> parents = new QChild().select(c.parent).where().c.parent.id.eq(1).selectAs(Parent.class).findList()
or even
// custom class that holds selected columns
class SelectedColumns {
Parent parent; // Should be a real entity managed by ebean incl. lazy load and such things.
String childName;
String otherName;
}
var c = QChild.alias();
List<SelectedColumns> rows = new QChild().select(c.parent,
c.name, c.otherEntity.otherName).where().c.parent.id.eq(1).selectAs(SelectedColumns.class).findList()
When coming from JPA chances are you have queries selecting an Object[] (or a custom class holding selected columns). In an app I just looked up ~200 uses of Object[] because queries select multiple columns that are not related to a single Entity. That is something that Ebean can not do and would need to code rewriting.
The main use cases why Object[] has been selected are:
- You want to index your query list result into a Map or Table structure. So you usually do "SELECT
x.id, relatedEntity" or "SELECT
x.id, yEntity, zEntity" or "SELECT
x.id, yEntity.id, zEntity".
- You want to workaround non-working JPA join fetches by selecting things manually in a flat Object[] or custom class and then work on the flat structure.
- In both above cases lazy load etc are still functional, since entities are managed by JPA.
-- J.