Details
Description
During benchmarks I noticed how renaming a feature type incurs in quite an overhead. Looking into it I discovered that a new RetypeingDataStore is created each time the renamed feature source is created. Due to the way the renaming datastore works, it requires to gather the full list of all type names from the original data store so that a getFeatureSource(name) request can be answered (the name transformation goes one way only, it's not meant to be necessarily invertible). When the wrapped datastore is postgis, this may require a lot of time (proportional to the number of layers available in the datastore).
It would be better to cache the renaming datastore as we cache the original ones. The alternative would require changing the retyping datastore so that it can do reverse name transformations... which I can do, thought it may not be trivial (and I would have to check the CITE tests pass on a fully renamed configuration).
Opinions? (btw, assigned to you just for the sake of discussion, I'll take it back when we have a decision)
+1. I see no issue with introducing a cache for retyped data stores. I guess the only issue would be how do we deal with things that change, like if the user changes the alias. I guess if the key to the cache is nativeName,alias this should not be an issue? As long as the cache can evict old values?
Anyways I would say proceed as you see fit and i will be happy to review the resulting patch.