[fdo-internals] SQL (Spatial) Azure

[Greg Boone]

Adding Brent and Orest explicitly for more detailed commentary, if required.

Some initial feedback....

>> * Would a new RFC be required for SQL Azure support or is it a ticket "fix"

[GB] As long as there are no FDO API changes, or changes to the fundamental behavior of any of the SQLServerSpatial commands, then it is a ticket "fix". 

>> * Should the embedded SQL code be unified - some of the limitations in SQL Azure require changes that could either be kept as specific to an Azure connection or the existing discovery SQL changed to be the same

[GB] Can we if/else these statements based on internal knowledge of the connection state? Ultimately unified SQL would be my first choice but not if it adds a great deal of uncertainty. We don't have a lot of QA cycles to test the impact of such changes. 

>> * At the moment it seems like some of the CreateSchema code is going to be tricky - permissions between master and other databases.  This is not of interest to us, so we are not looking at putting a lot of effort here... does that limit the scope of a submission to getting into trunk

[GB] If you know of cases where it will not work then issuing a clear exception to that effect would be required if such a scenario was encountered at runtime.


Greg


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Crispin_at_Linknode
Sent: Wednesday, May 29, 2013 4:27 AM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] SQL (Spatial) Azure

Hi,

We have put some research into the adaption of the SQLServerSpatial provider to allow connections to SQL Azure hosted databases.

We currently have a build on x32 and x64 that can be used for Connection
(some) DescribeSchema and FeatureReader API calls and as such we can use the provide within MapGuide to query and draw features - ya hoo!

A few things to air with the group before I get details written up:

 * Would a new RFC be required for SQL Azure support or is it a ticket "fix"

 * Should the embedded SQL code be unified - some of the limitations in SQL Azure require changes that could either be kept as specific to an Azure connection or the existing discovery SQL changed to be the same

 * At the moment it seems like some of the CreateSchema code is going to be tricky - permissions between master and other databases.  This is not of interest to us, so we are not looking at putting a lot of effort here...
does that limit the scope of a submission to getting into trunk

 * There is a really odd bug with spatial selection in MapGuide for point-layers with our build of the provider- where the selected objects are the *inverse* of an actual window selection (still need to see if that is also in the 3.8 release version)

Many thanks - Crispin




--
View this message in context: http://osgeo-org.1560.x6.nabble.com/SQL-Spatial-Azure-tp5056652.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals