Enhanced Join Support RFC

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Enhanced Join Support RFC

Ronnie Louie

Hi All,

 

A first draft of Enhanced Join Support RFC for MGOS is posted at http://wiki.osgeo.org/index.php/MapGuide_RFC_5_-_Enhanced_Join_Support.

 

Please have a look and post your feedback to this group.

 

Thanks

Ronnie Louie

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Enhanced Join Support RFC

Jason Birch
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

RE: Enhanced Join Support RFC

Haris Kurtagic
In reply to this post by Ronnie Louie
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.
 
Haris


From: Ronnie Louie [mailto:[hidden email]]
Sent: Friday, November 03, 2006 11:48 PM
To: [hidden email]
Subject: [mapguide-dev] Enhanced Join Support RFC

Hi All,

 

A first draft of Enhanced Join Support RFC for MGOS is posted at http://wiki.osgeo.org/index.php/MapGuide_RFC_5_-_Enhanced_Join_Support.

 

Please have a look and post your feedback to this group.

 

Thanks

Ronnie Louie

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Enhanced Join Support RFC

Jason Birch
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Enhanced Join Support RFC

Robert Bray-2
In reply to this post by Haris Kurtagic

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.

Bob

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.
 
Haris


From: Ronnie Louie [[hidden email]]
Sent: Friday, November 03, 2006 11:48 PM
To: [hidden email]
Subject: [mapguide-dev] Enhanced Join Support RFC

Hi All,

 

A first draft of Enhanced Join Support RFC for MGOS is posted at http://wiki.osgeo.org/index.php/MapGuide_RFC_5_-_Enhanced_Join_Support.

 

Please have a look and post your feedback to this group.

 

Thanks

Ronnie Louie

 

 

 


--------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Enhanced Join Support RFC

Ronnie Louie
In reply to this post by Ronnie Louie

Hi Jason,

 

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.

 

Ronnie

 

 

 


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 relationships.

 

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 service)

 

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 the logs.

 

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?

 

Jason

 


From: Ronnie Louie
Sent: Fri 2006-11-03 2:48 PM
To: [hidden email]
Subject: [mapguide-dev] Enhanced Join Support RFC

Hi All,

 

A first draft of Enhanced Join Support RFC for MGOS is posted at http://wiki.osgeo.org/index.php/MapGuide_RFC_5_-_Enhanced_Join_Support.

 

Please have a look and post your feedback to this group.

 

Thanks

Ronnie Louie

 

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Enhanced Join Support RFC

Jason Birch
In reply to this post by Ronnie Louie
CONTENTS DELETED
The author has deleted this message.