SQL (Spatial) Azure

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

SQL (Spatial) Azure

Crispin_at_Linknode
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
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email] [mailto:[hidden email]] On Behalf Of Crispin_at_Linknode
Sent: Wednesday, May 29, 2013 4:27 AM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SQL (Spatial) Azure

Orest Halustchak
Hi,

First of all, I think adding support for Azure will be an excellent enhancement. Thanks for doing this, Crispin!

Did you run into any issues with transactions when editing against SQL Azure?

As Greg says, clear exceptions for when create schema is not working will help as a starting point. I'm not sure that creating new schema when using Azure would be a major use case. It probably would be most common to access existing schema.

Thanks,
Orest.

-----Original Message-----
From: Greg Boone
Sent: Wednesday, May 29, 2013 10:00 AM
To: FDO Internals Mail List
Cc: Brent Robinson; Orest Halustchak
Subject: RE: [fdo-internals] SQL (Spatial) Azure

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: [hidden email] [mailto:[hidden email]] On Behalf Of Crispin_at_Linknode
Sent: Wednesday, May 29, 2013 4:27 AM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Reply | Threaded
Open this post in threaded view
|

Re: SQL (Spatial) Azure

Crispin_at_Linknode
Hi,

As you may have gathered from the lack of updates to this thread we ran out of time in developing this much further than the requirements we needed for a project.  So, although, not all the comments have been addressed it was important to record our findings and observations and post the code to a ticket so it can be used/reviewed/patched by others and hopefully start the process of SQL Azure support.

You can read the details here:
http://trac.osgeo.org/fdo/ticket/869

 Regards - Crispin