On 22 June 2011 11:23, Justin Deoliveira wrote:
> Hi Ian,
>
> On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton 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 eas
Hi Ian,
On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton 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 preferenc
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.
If you do stick with getJoins() is there are there good reasons to
make it return a list over a collection? I c
As Andrea says this was considered and discussed. And as Andrea kindly
pointed out the WFS spec actually mandates that we don't use multiplicity
and complex feature references.
That said I don't think we should rule out using the Join construct to do
that... just that I would like it to be an impl
Thanks for the review Andrea. Comments inline.
On Wed, Jun 22, 2011 at 1:01 AM, Andrea Aime
wrote:
> On Tue, Jun 21, 2011 at 1:35 AM, Justin Deoliveira
> wrote:
>
>> Hi all,
>>
>> The past couple of weeks i have been working on adding joins to the
>> geotools query api in support of joins in wfs
Different problem my suggestion was an alternative to having to repeat the
row:
>
>> Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
>> POI:SimpleFeature)
>> Park(fid:32, geom:Polygon, name:String,
>> Lake(fid:22):SimpleFeature, POI:SimpleFeature)
>>
> I think Justin already cl
On Wed, Jun 22, 2011 at 10:34 AM, Jody Garnett wrote:
> Different problem my suggestion was an alternative to having to repeat
> the row:
>
> Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
> POI:SimpleFeature)
> Park(fid:32, geom:Polygon, name:String,
> Lake(fid:22):SimpleFea
Different problem my suggestion was an alternative to having to repeat the row:
Park(fid:32,geom:Polygon, name:String, Lake(fid:21):SimpleFeature,
POI:SimpleFeature)
Park(fid:32, geom:Polygon, name:String, Lake(fid:22):SimpleFeature,
POI:SimpleFeature)
Or have a List:
Park(fid:32, geom:Polygon
On Wed, Jun 22, 2011 at 9:46 AM, Jody Garnett wrote:
> First +1 looks great; and thanks for providing readable code examples
> (the best way to sort out if the result will be readable).
>
> Have you considered using multiplicity to handle the issue of one or more
> features being returned on a jo
First +1 looks great; and thanks for providing readable code examples (the best
way to sort out if the result will be readable).
Have you considered using multiplicity to handle the issue of one or more
features being returned on a join? To steal from your example:
Park(geom:Polygon, name:Strin
On Tue, Jun 21, 2011 at 1:35 AM, Justin Deoliveira wrote:
> Hi all,
>
> The past couple of weeks i have been working on adding joins to the
> geotools query api in support of joins in wfs 2. The work goes well and i
> have a working implementation for the jdbc modules that has been tested with
> p
On Tue, Jun 21, 2011 at 7:53 AM, Andrea Aime
wrote:
> On Tue, Jun 21, 2011 at 3:33 PM, Justin Deoliveira
> wrote:
>
>> Hi guys,
>>
>> Yes, the ability to join on custom filters was done intentionally, mostly
>> to support spatial joins. If app-schema were to move to this api for joining
>> for th
On Tue, Jun 21, 2011 at 3:33 PM, Justin Deoliveira wrote:
> Hi guys,
>
> Yes, the ability to join on custom filters was done intentionally, mostly
> to support spatial joins. If app-schema were to move to this api for joining
> for the time being maybe it would be possible just to throw an excepti
Hi guys,
Yes, the ability to join on custom filters was done intentionally, mostly to
support spatial joins. If app-schema were to move to this api for joining
for the time being maybe it would be possible just to throw an exception.
If you look at the join class it has a Type property which is a
Hi Justin,
Your proposal looks a lot like what I did in the 'JoiningQuery' class in
app-schema.
The difference is though that this supports joining on custom filters
while my implementation only allows to joining field expressions to be
specified (so there is always a "=" comparison).
I think
Hi Justin,
part of the semantics of a SQL join is that it may return multiple
rows per "feature" (row in joined table) - one for each possible join.
The examples dont cover this case, because of disjoint nature of
parks, but if you had for example parks within parks then you would
get multiple hit
16 matches
Mail list logo
