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?
Gabriel
> Jody
--
Gabriel Roldan
http://www.opengeo.org
------------------------------------------------------------------------------
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
