I just realized that the proposed api will actually cause a complication
failure in app-schema, due to JoiningQuery which subclasses query and adds
getJoins() but returns a different class called Join.
app-schema folks: what are your thoughts? the two classes are significantly
different. Any chance of merging them? Or perhaps making the one in
app-schema a subclass of the new Join class?
On Wed, Jun 22, 2011 at 9:34 AM, Ian Turton <ijtur...@gmail.com> wrote:
> On 22 June 2011 11:23, Justin Deoliveira <jdeol...@opengeo.org> wrote:
> > Hi Ian,
> >
> > On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton <ijtur...@gmail.com> wrote:
> >>
> >> It looks good to me so +1.
> >>
> >> My small niggle is the use of
> >>
> >> query.getJoins().add(join1);
> >>
> >> where I might prefer:
> >>
> >> query.addJoin(join1);
> >>
> >> which might be easier for users to spot in the API.
> >
> > I don't have a strong preference but I tend to stay away from doing that
> in
> > apis and instead just make the collection available. Reasoning being that
> > you are start to have to turn the containing class (in this case Query)
> into
> > a collection type, give it a getNumberJoins() method, removeJoin(),
> etc...
> > which imo pollutes the api.
> >>
>
> That is a good point - but may be an addJoin() convenience method and
> getJoins for everything else. I suspect most users will be just adding
> a join to their query.
>
>
> >> If you do stick with getJoins() is there are there good reasons to
> >> make it return a list over a collection? I can't work out if it is
> >> important to force an ordering to joins or not.
> >
> > I do think ordering is important, if for anything to determine what order
> > the attributes will be in the resulting feature type. It would seem
> strange
> > to do:
> > query.getJoins().add(new Join("type1"))
> > query.getJoins().add(new Join("type2"))
> > But then have the feature type return them in the order "type2", "type1".
> So
> > I guess my answer would be "any reason not to make it a list"? :)
>
> That is exactly the reason that was hoovering in the back of my mind
> that I couldn't pull forward. A list is fine - I just wanted to check.
>
> Ian
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
