The Database as an Alternative to the GAC

Based on initial investigations of storing source code in the database, I’m now focusing on storing assemblies in the database, serialized as blobs. Doesn’t make sense to be recompiling all the time. Instead, I just serialize the dll file as a byte array, then store that via memoryblobstream to a blob field. Deserialize using System.Reflection.Assembly.Load(Byte[]). In effect, this allows using a DBMS in lieu of the GAC (Global Assembly Cache).

The deployment issues this addresses are not peculiar to GIS, yet I can’t find much discussion of this. I’d be interested in hearing from anyone who has tried this. Treating code as data is receiving attention these days, so why not store assemblies in the database?

ESRI’s discussion of Enterprise DBMS seems to avoid discussing the inability to centrally manage business rules using triggers in a versioned geodatabase. I’m working on an Editor Extension that manages triggers instantiated from a database assembly cache to compensate for this.

Another common use of editor extensions is to trigger some code in response to editor events. (from “About Editor Extensions” in EDN)

It seems like a domain specific language could be derived that focuses specifically on managing triggers, similar to the approach described here by the Mechanical Bride, except the DSL code would be compiled into an assembly that would then be stored in the database.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: