List<Name> is the way to go; we need some control over attribute order in
the result (at least to be able to match XML schemas where such a thing has
been defined using a sequence. I actually wonder if this is an area where we
could simplify our model some - I am still waiting for an "unordered"
example to appear in the real world.
So we have three things on the table here:
1. Query needs to be extended to have List<Name> - that is cool lets do it
2. SimpleFeatureTypeBuilder is not suitable; Ben can feel free to start
making his own builder ....
- or to just use the factory methods directly if that is easier for him to
start out
- I would like to put off defining a builder until we have some experience?
and then just use the refactor "inline method" to help define the builder.
- I expect the FeatureBuilder will not provide as much help in defining
attributes; since it will more strictly expect add( Name,
AttributeDescriptor )
3. Encoding / (and parsing if we expect Transaction to work)
- my preference would be to go with the binding framework and use that as an
excuse to increase performance. Although this is a low priority since we
need to focus on capability first. Andrea can we make the decision what
system to use based on if SimpleFeatureType is used? That way we can avoid
taking the performance hit for the vast majority of cases - and buy more
time to work on performance.
On Sat, Feb 28, 2009 at 9:32 AM, Rob Atkinson <robatkinson...@gmail.com>wrote:
> 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
>
------------------------------------------------------------------------------
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
