DontInitialize AutoQueryCollections missing on NuGet Package 4.5.10

ServiceStack Auto Query
1

It seems this was removed in the latest version. We were running 4.5.8 and just attempted upgrading and this code is no longer valid:

var nativeTypes = this.GetPlugin<NativeTypesFeature>();
nativeTypes.InitializeCollectionsForType = NativeTypesFeature.DontInitializeAutoQueryCollections;

Is this now just default behavior for AutoQuery?

2

Yep it’s no longer needed as Empty Collections are now ignored in AutoQuery.

1 Like
3

I’m using SS 6.6 and I’ve encountered a scenario where I want the generated DTOs to have constructors which initialise collections, but I don’t want that for the AutoQuery DTOs.

I don’t want it for AutoQuery DTOs because I don’t want the requests to be filled with empty noise, as I use the query params as part of a cache key for caching AutoQueries - and it doesn’t take much to push the cache key length over the 900 character limit of MSSQL for primary keys of the CacheEntry table. Even less than 900 characters for MySQL/MariaDb.

Also, it offers no convenience to the consumer to have these initialised, as they typically only ever get set.

I could parse the query params in my service and remove all the empty parameters before using it as part of the cache key, or is there a way to control in the AppHost which properties are initialised by the NativeTypes code generation feature?

4

You can’t distinguish them between which types they should be initialized, but using C#'s Target-Typed New Expressions makes it painless to initialize them now, e.g:

var request = new MyRequest {
    Collection = new() { Item },
}

Is there a particular use-case where they’re tedious to initialize?

5

Not really - It’s just I’m cautious of changing the existing behaviour / expectations for consumers of our API more than anything.

We do have complex DTO’s which have many different lists and items in those lists have properties which are also lists and so on - it’s not the end of the world, but in exploring options I came across the old topic in which you introduced DontInitializeAutoQueryCollections and I saw that and felt it solved all my problems… only to find this very topic here announcing its demise.

I think you’re right - I should just default to have InitializeCollections=false and be done with it - it’s not that much of a burden for those using the generated DTOs to have to initialise those properties themselves.

Thanks.

1 Like
6

Upon review I agree it doesn’t makes much sense to initialize AutoQuery collections by default, especially with the target-typed new expressions removing previous boilerplate, so I’ve changed it to no longer initialize AutoQuery collections in this commit which is now available on MyGet.

Previous behavior can be restored with:

ConfigurePlugin<NativeTypesFeature>(feature => 
  feature.ShouldInitializeCollection=NativeTypesFeature.AllCollectionProperties);
1 Like