Yeah, this sound about right. If I remember correctly is that everything is
"joined" to the feature type defined by the main query itself. Quite
honestly the implementation approach was to do the minimum to check for the
box for wfs 2.0 testing. It has been a while since I looked at this code so
hard to say how many modifications doing full joins would require. I
imagine in the least some additions to the JOin class itself and then
updates to the actual methods that encode the joins, for which there is a
handful.
On Thu, Jun 12, 2014 at 10:21 AM, Andrea Aime <[email protected]>
wrote:
> Hi,
> looking at join support in WFS 2.0 I _believe_ to have discovered a
> limitation
> in the way joins are implemented by looking at a 3 way join and then
> generalizing the issue to a N way join.
>
> Basically, the way joining has been implemented allows to join a central
> feature type FT1
> to any other feature type, but you cannot create a chain of joins that
> does not have a central element.
>
> In other terms, it's possible to do a "star join" with a central element
> joined to
> everything else:
> (FT1 join FT2) and (FT1 join FT3) and (FT1 join FT3) and ... (FT1 join
> FTN)
> but not a "chain join" with no central element:
> (FT1 join FT2) and (FT2 join FT3) and (FT3 join FT4) and ... (FTN-1 join
> FTN)
>
> Now, limited to the 3 way case, it's possible to do a rewrite to create
> the central element,
> from:
> (FT1 join FT2) and (FT2 join FT3)
> to:
> (FT2 join FT1) and (FT2 join FT3)
> thus respecting the "central feature type" structure.
>
> Buf the moment we go to a 4 way join, the thing falls apart.
> The way I understand things, to make a "chain join" possible, we'd need to
> allow
> a Join to have sub-joins just like Query, and the particular case of
> chain join would be represented as:
>
> Query(join1(join2(join3(....(JoinN))))
>
> Any feedback?
> Do you have a feel of whether that would require major changes to the JDBC
> store?
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/NWWaa2 for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
[email protected]
@j_deolive <https://twitter.com/j_deolive>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
