Attribute order is in fact important. ISO have specified a "implementation hint - aka a UML tag - for attribute order. Simon Cox tells me is a technically mandatory part of the meta-model for features - I'll chase dow the reference if anyone cares that much :-) .
Rob On Sat, Feb 28, 2009 at 3:15 AM, Andrea Aime <aa...@opengeo.org> wrote: > Gabriel Roldán wrote: >> On Thursday 26 February 2009 02:04:15 Jody Garnett wrote: >> > On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies >> > >> > <ben.caradoc-dav...@csiro.au> wrote: >> > > Justin Deoliveira wrote: >> > >> Changing the Query API will affect every DataStore. If this is done by >> > >> >> > >>> expanding Query and DefaultQuery as you indicated, it should be >> > >>> possible to leave the existing DataStore implementations untouched. >> > >> >> > >> Can we modify the Query interface in a way we don;t have to modify all >> > >> datastores? What I mean is is keep String[] getPropertyNames() in >> tact, >> > >> but add a Name[] getProperties() or something. Internally we can store >> > >> the qualified names. >> > > >> > > Yes, exactly. Jody suggested extending the API with a List, but I was >> > > thinking: >> > > Collection<Name> getProperties() >> > >> > I think we still need a List in order to allow people to specify the >> order >> > of the resulting properties? >> which by the way does not make much sense after all. I mean, in the >> feature model there's no such a thing as the order of the properties. We >> always used to do that with simple features, somewhat mirroring a flat >> table query in a database, but I guess the question is do we want to >> keep forcing that behaviour or would Query.getProperties():Set<Name> >> make more sense? > > I see an issue here: > String[] getPropertyNames gives up namespace support (which Ben says is > part of the simple feature spec) but gives you control over the order > of the property as returned by the query. > > Set<Names> getProperties gives up namespace support, but won't allow > control over the order of the returned properties. I know that xml > wise we cannot break the feature type specified order, but I'm pretty > use there is code that would break if we don't allow order control > (I for one never use getAttribute(String) if possible to avoid the > extra hashmap lookup). > > List<Names> would give the best of both worlds it seems? > > Cheers > Andrea > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
