I was hoping to avoid talking about history and the philosophy of this,
but it looks like I have no choice. The original implementation of
Joins in the new MapGuide architecture was written as an FDO provider.
From the start conceptually it seemed like the right thing to do.
However a number of things became somewhat complex, with the following
two eventually leading to its demise:
1. Configuring joins. The Join Provider wound up having a fairly
complex configuration document that could not be represented naturally
in the UI.
2. Implementing update through the provider was just plain hard and the
reality is most use cases don't require it. As long as you can easily
determine the left and right hand sides, it is fairly straightforward
to update directly through the primary or secondary source.
Instead we eventually decided to build a new level of service APIs on
top of FDO. Join became one of the first components in this new tier of
services. You can find separate component for implementing joins in the
MapGuide source tree. This same Join component is also used in some
other commercial software and could be used in any client outside of
MG. The other change in this newer architecture is that Joins are now
defined in the Feature Source XML of the primary (or left hand side)
data source. This makes in very natural in the client to navigate to
that Feature Source and then extend it via a Join to another Feature
Source. This model also makes it easy to determine the primary (LHS)
and secondary (RHS) Feature Sources for performing updates without
diving into the intricacies of provider configuration documents.
Haris Kurtagic wrote:
I suppose Join is most
interesting for file based data sources ?
It looks to me that for rdbms
data sources this is "natural" stuff to do.
In that context, I have a
feeling that this could be something for FDO level not MG.
One of advantages would be that
join functionality wouldn't be just to MG but other clients also.
Perhaps little crazy idea but I
also could imagine having a "join fdo provider" which will do the work
for join for classes across providers.
Louie [[hidden email]] Sent: Friday, November 03, 2006 11:48 PM To:[hidden email] Subject: [mapguide-dev] Enhanced Join Support RFC
Thanks for your comments. Your
suggestions for handling 1:many are duly noted, however it is not proposed as
part of this RFC. As Bob mentioned earlier in a previous email, the join
functionality is implemented via a Join component which is also shared with
another commercially available product. Changes were discussed to support
“associations” of a primary feature record to a set of secondary
records, but ultimately did not make it into that product’s release
cycle. I can only speculate that this support may be part of a future
release. As a result, MapGuide will be restricted, for now, to the “lazy
join” result for the 1:many case.
As for your question on the SDF joins, it
should be possible to join secondary table to a primary table in the same SDF
or different SDF file. I haven’t personally tested this, but if you’ve
got SDFs with multiple tables, you should be able to see a list of all the available
feature classes in the Studio Join UI for which you can use to define you join.
From: Jason Birch
[mailto:[hidden email]] Sent: Friday, November 03, 2006
4:21 PM To:[hidden email] Subject: RE: [mapguide-dev]
Enhanced Join Support RFC
Overall, I like this proposal. I think that the 1:many support is
probably a good first step. It makes it easier to query secondary data
sources and return geometry.
However, it is really just a right outer join, and does not provide for
some of the most common map operations that will be required with 1:Many
In particular, it will not be able to support maptips
(display all owners for a parcel), queries (only show properties with more than
one service connection) and theming (color ramp based on number of calls for
I think that this would be best dealt with in two ways.
First, I would like to see an option to return a single geometry row, with a
nested rowset representing the "Many" records. Second, I would
like to see the option to return a single geometry row along with some basic
aggregate (sum, min, max, mean, group_concat) and search (contains)
results, essentially acting as a GROUP BY operator on the root geometry.
These could even be combined, allowing both the aggregate functions and the
nested results to be returned.
I understand that this is a big request, but I thought I'd reiterate it
here. It was discussed in IRC after the last meeting, but I don't have
I also have a question about why spatial and aspatial data sources are
so segregated in Studio. I may just be a bit fuzzy, but is it possible to
join a secondary table in an SDF file to a primary table in the same SDF
file? In another SDF file?
Louie Sent: Fri 2006-11-03 2:48 PM To:[hidden email] Subject: [mapguide-dev] Enhanced
Join Support RFC