MapGuide tidbits: Is your FDO provider smart enough when handling SQL?

So if you saw my previous MapGuide/pgRouting example, I mentioned that the whole example was only possible because any SQL queries (that involves geometry columns or expressions) that we send off to PostgreSQL through the MapGuide API, the FDO provider correctly translates such column values back into FDO geometry values and not as un-readable BLOBs.

Although we can't directly create a layer off of such a query, we can still feed the query result into a temporary SDF/SHP/SQLite feature source and create a layer off of that instead, which is how we got to display the shortest path results in MapGuide from a pgRouting SQL query.

So how do you know if your FDO provider:

 a) Supports SQL?
 b) Is smart enough to translate any geometry values in a SQL query result into FDO geometries and not un-usable BLOBs?

Simply connect to this database through the FDO provider with FDO Toolbox and launch a Data Query.

Do you see a SQL query mode in the Data Query tab? Then the provider supports SQL commands

When you run a SQL query in the Data Query tab, do you see WKT in the geometry column in the results pane?

If so, the provider is probably correctly translating these values back into FDO geometries.

But just to be sure, can you see the result visually?

If so, then there is no doubt that your provider is smart enough, and when the FDO provider can handle such cases, you can pretty much tap into whatever spatial functionality your underlying database has to offer through SQL if the standard MapGuide/FDO APIs do not fit the bill, as was the case in our MapGuide/pgRouting example.