How can I leverage an ORM for a database whose schema is unknown until runtime?

Question

I am trying to leverage ORM given the following requirements:

1) Using .NET Framework (latest Framework is okay)
2) Must be able to use Sybase, Oracle, MSSQL interchangeably
3) The schema is mostly static, BUT there are dynamic parts.

I am somewhat familiar with SubSonic and NHibernate, but not deeply.
I get the nagging feeling that the ORM can do what I want, but I don't know how to leverage it at the moment.

SubSonic probably isn't optimal, since it doesn't currently support Sybase, and writing my own provider for it is beyond my resources and ability right now.

For #3 (above), there are a couple of metadata tables, which describe tables which the vendors can "staple on" to the existing database.
Let's call these MetaTables, and MetaFields.

There is a base static schema, which the ORM (NHibernate ATM) handles nicely.
However, a vendor can add a table to the database (physically) as long as they also add the data to the metadata tables to describe their structure.

What I'd really like is for me to be able to somehow "feed" the ORM with that metadata (in a way that it understands) and have it at that point allow me to manipulate the data.

My primary goal is to reduce the amount of generic SQL statement building I have to do on these dynamic tables.
I'd also like to avoid having to worry about the differences in SQL being sent to Sybase,Oracle, or MSSQL.

My primary problem is that I don't have a way to let ORM know about the dynamic tables until runtime, when I'll have access to the metadata

Edit: An example of the usage might be like the one outlined here:

IDataReader rdr=new Query("DynamicTable1").WHERE("ArbitraryId",2).ExecuteReader();

(However, it doesn't look like SubSonic will work, as there is no Sybase provider (see above)

Answer 1

Acording to this blog you can in fact use NHibernate with dynamic mapping. It takes a bit of tweaking though...

Answer 2

We did some of the using NHibernate, however we stopped the project since it didn't provide us with the ROI we wanted. We ended up writing our own ORM/SQL layer which worked very well (worked since I no longer work there, I'm guessing it still works).

Our system used a open source project to generate the SQL (don't remember the name any more) and we built all our queries in our own Xml based language (Query Markup Language - QML). We could then build an xmlDocument with selects, wheres, groups etc. and then send that to the SqlEngine that would turn it into a Sql statement and execute it. We discusse, but never implemented, a cache in all of this. That would've allowed us to cache the Qmls for frequently used queries.

Answer 3

I am a little confused as to how the orm would be used then at runtime? If the ORM would dynamically build something at runtime, how does the runtime code know what the orm did dynamically?

"have it at that point allow me to manipulate the data" - What is manipulating the data?

I may be missing something here and i aplogize if thats the case. (I only have really used bottom up approach with ORM)

Answer 4

IDataReader doesn't map anything to an object you know. So your example should be written using classic query builder.

Answer 5

Have you looked into using the ADO.NET Entity Framework?

MSDN: LINQ to Entities

It allows you to map database tables to an object model in such a manner that you can code without thinking about which database vendor is being used, and without worrying about minor variations made by a DBA to the actual tables. The mapping is kept in configuration files that can be modified when the db tables are modified without requiring a recompile.

Also, using LINQ to Entities, you can build queries in an OO manner, so you aren't writing actual SQL query strings.