AutoQuery additions/flexibility
It would be useful to have AutoQueries that could do
1. custom joins (currently, you have to write a service 'override')
2. generic, dynamic, or object as a return type!
Potentially makes writing dozens of reports easy to maintain (for our department) because they are maintained from their source objects instead of having a DTO for each one, considering that regular joins already work that way where they do not require a custom return type to return!
M Petros
shared this idea
Custom joins can’t be declared in a class definition, you would need to use a Custom AutoQuery implementation.
AutoQuery Services require populating a Typed Response DTO which is what’s needed to indicate which columns to return. Unknown return types can’t be documented in metadata services and can’t be consumed in any supported language which requires deserializing into a known type.
-
The return Type is used to tell OrmLite which columns to select and populate. AutoQuery always needs one and all Services should have a defined schema in order to work with existing metadata services and existing languages.
-
M Petros
commented
In reference to your second statement: is that because the front end cannot know about which columns to return because they are dynamic (and will always) or they can but it is not really performance friendly?