MasterCatalog overrides Resources
ridoo opened this issue · 7 comments
Problem Description:
Data sources can be referenced via QUrl containing a query string. Currently the MasterCatalog is not prepared for this as it references each Resource by its URL without its fragment (if available) and without its query.
A WFS provides access to its features by query URLs, e.g.
Proposed Solution(s):
The MasterCatalog could use appropriate keys which do not only contain the base URL but the full URL. Not sure right now if this really solves the whole issue.
full url in the mastercatalog ( no splitting) should be sufficient and should be allowed. It might be benificial to store the elements of the query also as properties as it makes it easier to search for certain properties in the query (mastercatalog is basically 2 databastables). I close this issue as I simply agree with you. If the current behaviour of the mastercatalog doesnt support it, it is simply a bug
so it is a bug and I reopen the issue :)
To give a concrete locations on this:
In MasterCatalog addItems(QList<Resource>& items) starting from line 166
if ( mastercatalog()->contains(resource.url(), resource.ilwisType()))
continue;
_knownHashes.insert(Ilwis::qHash(resource));
The hash is calculated by using url and ilwis type:
uint Ilwis::qHash(const Ilwis::Resource& resource ){
return qHash2(resource.url(), resource.ilwisType());
}
So storing url and query separatly in Resource would cause references to be overridden when multiple data sources have the same base url
ok, i might be mistaken but the query is not split off as far as I can see. The annoying part is that the debugger doesnt show the query but it is still there. At least I checked the setname method and it retains the query. Granted I can only check for the simple cases with codes(that have a query) but I suppose it works similar for service urls's
@MartinSchouwenburg .. last week I showed you the location where the resource might split the query ... did you have a chance to see what's going on?
As far as I can see, a resource URL is being adapted within setName when creating a resource via an QUrl. However, as setName adapts the URL by default is resource url is being reset by the string representation of QUrl (which is rather confusing side effect for calling setName by the way)
Starts to get confusing now ... I digged in a bit deeper and see that IlwisObjectConnector may cause the issue, as it creates the object using the container URL rather than taking the URL from the resource itself ...
as far as I can see it, it creates a container connector based on the container of the resource which seems quite reasonable to me. I think we will need to look into it when the next time you are here. The urls I use are (very) limited in their "query" payload so we will need to look at an example of you to see what exactly happens. As far as I can see there will be no problem in retaining the query in the url, so I don't expect serious issues.