I suggest you ...

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!

3 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
M Petros shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
declined  ·  AdminDemis J Bellot (Developer, ServiceStack) responded  · 

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.


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • AdminDemis J Bellot (Developer, ServiceStack) commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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?

Feedback and Knowledge Base