Hi Justin,
Sorry for the late response, lost track of this a bit.
Rather than being needlessly complicated I believe I have caused
confusion by giving these two methods the same name - I should not
have done that. What they have in common is that they both convert
from Name to PropertyName, other than that they serve a completely
different purpose.
Right, so let's rename the method. What would be a good name?
It is the method in the record descriptor that translates between
the internal and exposed data model.
The method in the store is merely there to tell what sort of
conversion we need for a particular purpose; this is different in
both stores for very good reasons, which I could elaborate. By
creating the method it is possible to keep a bunch of other code
the same for both stores. It's all been a part of the process of
making code more generic and prevent copy-pasting, and simplifying
- not complicating things. I should be more careful with name
choosing to avoid confusion though.
Makes sense. Maybe you could elaborate on how the method operates
differently for both stores, if anything so we can come up with a
suitable name?
So, it is being used for GetRecords with properties selection. Also for
GetDomain but that is just a special case of the same thing.
The simple catalog store will select the properties after building the
feature using RetypingFeatureCollection, as it was already done. This it
the easiest way to do it in this case. The user's specified property
names are the ones we need.
In the case of the internal catalog store, the situation is different.
You cannot use the RetypingFeatureCollection because we are working with
nested complex feature structure here and the properties can be paths.
However the properties can also be names that are sort of shortcuts for
the paths but don't reflect the structure of the feature at all (see the
iso metadata standard). And why build too much of the feature? Can make
it considerably slower in this case. So that is why I select the
properties on the level of the mapping, I cut down the mapping. It makes
most sense here. So now the property names need to be understood by the
mapping, i.e. we need a full translation of the property.
I guess you could call the method preparePropertyForSelection or
something. The reason I made an extra method, is because the query wants
PropertyNames, not Names, so they need to be passed as such in the query
by whoever is calling the RecordStore. An alternative approach that
would work in this case is to only do the basic conversion from
propertyname to name and then let the internal catalog store do the
extra conversion in the beginning of the getRecordsInternal method. If
you really want to get rid of it, it seems like that should work as
well, now I look at it again. I seem to remember there was a reason I
didn't do that though, but I can't quite remember. The way I did it
seemed the most logical at the time working from the existing code to
make it more generic and support future alternatives.
Question. For RecordDescriptor.translateProperty is the "translation"
one way, from the internal model to the exposed model?
And similarly for the CatalogStore.translateProperty method, is the
mapping from the exposed model to the internal model?
For RecordDescriptor: No, the other way around, from exposed to internal.
For CatalogStore: in the case of the simple store (or the default case)
it does not do this, it merely converts from Name to PropertyName.
Cheers
NIels
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
