Add Execute_SQL or ExecuteSQL functionality to ESRI Runtime APIs

659
1
03-16-2016 03:10 PM
Status: Open
RobRader1
New Contributor III
Background:  SQLITE has extensibility and is available across platforms. Many pieces of functionality are provided for performance. In both the ArcObject and the ArcGIS Pro SDK, the Iworkspace.Execute_SQL or ArcGIS.Core.Data.DatabaseClient.ExecuteStatement allow for direct SQL injection.
 
 
Workflows: 
#1 : Initially this request was being made so that we could provide localized data enhancement using ST_GEOMETRY. To use ST_GEOMETRY, or insert shapes at all, requires functionality provided by an external dll. To create a cross platform tool, such as using QT would require loading of that DLL in different ways for each platform. Where as the runtime has already initialized the st_geometry on the current workspace in use.
 
#2 SQLite, has may parameters available for tuning performance. As a business partner trying to enhance the data experience for end users, we may need to set the connection busy timeout or other parameters which are connection specific as part of processing done.
 
#3 We are being asked to move all of our future processing work, data enhancement, to the client side rather than in the ArcSDE database. I personally support this network as a service model and other functionality only being available to write to through service end points. It however means we are going to need to do complex logic translation moving from the SQL model of pl/sql or transact sql to a SQLite set of functions. Although we can initialize a workspace using the cross platform libraries, we will need to tweak the cross connection logic at the database level. Putting in a cross connection lock or other functionality is historically done in the data source used, to make sure multiple processes stay in sync, even across multiple machines. Yes, I do envision a scenario where there are runtime processes on multiple machines hitting the same SQLite datastore to quickly perform a data enhancement task.That cross machine logic could take advantage of SQLite’s locking mechanism, similar to what we do with SDE today.
 
 
As developers using a runtime client against SQLite,  we will own the validation of the tools that take advantage of the advanced options.  It is understood therefore some at ESRI may think that this functionality is ‘dangerous’. Please remind these individuals that the reason for the move out of the SDE and to client side, is so that this processing is safer than  doing it straight in SDE today. 
 
Thank you for your consideration.
1 Comment
TimLangner
In what way for the functionality be dangerous?