On Mon, Dec 20, 2010 at 6:10 AM, Niels <niels.charl...@csiro.au> wrote: > On 18/12/10 17:12, Andrea Aime wrote: >> >> On Fri, Dec 17, 2010 at 9:03 AM, Niels<niels.charl...@csiro.au> wrote: >>> >>> I think you do need a NameSpace context in your query, because you cannot >>> assume that the namespace prefixes in the property names of the query are >>> the same as the ones in the mapping or in the datastore or anywhere else. >>> The thing about namespace prefixes is that you can never make those >>> assumptions. >>> Another solution for Query would be to provide a list of PropertyNames >>> rather than strings (which is what I suggested earlier I think?) but I >>> guess >>> that would break too much existing code ? >> >> Lucklily Query is not an interface anymore so it _would_ be possible to >> just add PropertyName (or Name) support and have it fall back on plain >> strings when the plain string methods are called. The new methods >> would be used only by code that know about complex features. > > I think that is an excellent idea actually... Have two getters and settesr > for PropertyNames property in Query: one with string[] and one with > PropertyName[]. The inner representation of the property names in the class > could be PropertyName[], but when the string[] getter and setter are used, > conversion is done automatically. > > I think that would be even better than having a setNamespaceContext() in > Query!
Soo... is it confirmed that Query will use PropertyName as the way to specify the property names? I need to align with this development in GeoServer's GSIP 57 For the time being I'm going to assume it's headed that way as I need to start coding it :-) Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
