Early adopter feedback before 1.0

[rey5137]

Model Query is 0.x: every public type is @Incubating until the 1.0 API freeze, so now is when your feedback can still change the API. Tell us:

• what you tried it on (JPA provider, database, Spring or not)
• which query you could not express, or had to write awkwardly
• any name or signature that surprised you

Bugs go to Issues; anything else goes here. Start with the comparison with JPA, Querydsl and Blaze-Persistence and the plain-JPA sample, which runs with one command:

./mvnw -q -pl samples/plain-jpa -am package -DskipTests -Prun

[rey5137]

RFC for feedback: looking up a model's fields by name (rfc/0006)

The use case is a search API where the client chooses the fields, for example ?fields=id,status,customer.name. Today the app has to keep its own map from strings to Q constants, and that map drifts from the model.

The proposal is that each generated Q<M> gets a fields() method returning a FieldIndex<M>, keyed by the same property paths that sort names already use:

private static final FieldIndex<OrderView> API_FIELDS =
        QOrderView.fields().only(List.of("id", "status", "customer", "customer.name"));

var resolved = API_FIELDS.resolve(requestedFields);   // never throws; unknown names come back in resolved.unknown()
var query = QOrderView.query().select(resolved.select()).build();   // the customer join is added only when it's selected

It only resolves names. Which fields to expose, how the response is shaped and how values are parsed stay in your code.

I'd like opinions on these:

1. Should only(...) also take aliases (customerName → customer.name), or should renaming stay in the app?
2. Should items.code choose a child's own fields (building the fetch plan for you), or is that too much?
3. Would you use a matching Spring binding for a fields request parameter, like the one for Sort?
4. Do you build APIs like this today (REST field selection, GraphQL, saved reports)? How do you map the names now?