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

Reply via email to