Justin Deoliveira ha scritto: > Hi all, > > I just committed a change to the Data class which handles lookups for > feature info objects with un-prefixed names. The basic logic is that if > there is only name that matches, that will be the one returned. I also > had to add some logic around the layer type lookup since if an > un-prefixed name is handled with a direct feature type info lookup, it > should be handled when a layer type lookup is done with the same name. > > It is not a huge change but nontheless it is a commit to core code so I > would like a review. The commit is revision 8593. I can back the change > out easily if there are issues.
Hum, I had a look at the patch and it seems ok code wise. The usual steps are followed anyways: * try a full match * try adding the default namespace prefix in front of the name and then the full match by name is tried. Yet, I'm not sure I understand why we need to match the unprefixed names out of the default namespace... that is, we never had this behaviour. It this patch related to http://jira.codehaus.org/browse/GEOS-1816? In that case the layer name was states, so prefixing it with the default namespace should have done the trick? I'm just trying to understand what's the use case for this. Think of the consequences. You have a certain feature type "XX" in a non default namespace, you make an unprefixed request, you get back data. Then you add another "XX" in a different namespace and boom, the previous request stops working because now you have two (the patch returns a feature type only if it can find one instance). Or you add a new "XX" to the default namespace, and you start getting back completely different data (since the one in the default namespace is looked up before the unprefixed match attempt). Yet, you can get a similar mess with the old code as well, you just have to change the default namespace and all your unprefixed queries go bye bye. Yet it seems to me the patch might increase this confusing behaviour. Opinions? Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
