ServiceStack.OrmLite: Selecting POCOs where Type is determined in runtime (inheritance)

Question

How can I properly deserialize POCOs using OrmLite from ServiceStack when I dont know the exact type of the POCO at design-time, but I only get a Type at runtime?

So, something like this:

// Returns the object and can be cast to the correct subobject
public BaseClass ReadObject(Type typeOfObject, int id) 
{
     using (var db = _dbFactory.Open())
     {
         baseObject = db.Select<BaseClass>(typeOfObject, id);  // need something here...
         return baseObject;
     }
}

...
BaseClass bc = ReadObject(someType, 3); // someType = Customer for example

...
class BaseClass { ... }
class Actor : BaseClass { ... }
class Customer : Actor { ... }
class Operator : Actor { ... }

I am persisting Actor and Customer, but when I read them back, I basically only have a Type and possibly the primary key. The .Select<> doesn't work, as I need to know the type at runtime.

I found this SO: Create (and select from) a table dynamically using servicestack ormlite

And if I understand correctly, the only way to fetch a POCO where the type is not known at design-time, is to do a manual SQL statement, like in the answer:

var modelDef = employeeType.GetModelMetadata();
var tableName = db.GetDialectProvider().GetQuotedTableName(modelDef);
var sql = $"SELECT * FROM {tableName}";

var results = db.Select<List<object>>(sql);
var results = db.Select<Dictionary<string,object>>(sql);
var results = db.Select<dynamic>(sql);

However, this does not create any of the classes listed at the top; I need it to typecasted to BaseClass, but it should of course be the correct object (so, 'Customer', 'Operator', etc).

How do I achieve this?

(I have also noted that Mythz has said that using inheritance when persisting data is a bad idea and that he proposes to "flatten" the hierachy. However, I would stick my neck out and say that when dealing with Object Oriented languages, inheritance and polymorphism is unavoidable and not something 99.9% of the coders out there can do away with ;-))

Answer 1

There is very limited support for using runtime types in OrmLite.

See OrmLite's Untyped API Support which gives you access to some Insert, Update and Delete APIs when dealing with runtime types.

But SELECT's need to specify the concrete Type to select into, i.e. you could select into the base class with:

var results = db.Select<BaseClass>(typeOfObject);

But results would only populate the BaseClass properties.

One potential solution is to use the Dynamic Dictionary ResultSets API to select results into a list of object dictionaries, e.g:

 List<Dictionary<string,object>> results = db.Select<Dictionary<string,object>>(q);

Then use FromObjectDictionary Reflection Utils to convert it to a late-bound Type, e.g:

List<BaseClass> customers = results.Map(x => (BaseClass)x.FromObjectDictionary(customerType));

Quoting sources

(I have also noted that Mythz has said that using inheritance when persisting data is a bad idea and that he proposes to "flatten" the hierachy. However, I would stick my neck out and say that when dealing with Object Oriented languages, inheritance and polymorphism is unavoidable and not something 99.9% of the coders out there can do away with ;-))

If you're going to quote someone, please do so verbatim including a link to the source you're quoting as this is a misrepresentation of what I've said.

You're likely referencing my answer highly recommending against using inheritance and base type properties and unknown late-bound types like interfaces and objects in DTOs. This is to avoid coupling to specific serialization implementations and is a major source of runtime serialization issues which is contra to the goals of creating well-defined interoperable Services. You can avoid this guidance but your services will only work with specific serializer implementations, fail in different languages and have limited metadata support as they'll be unable to statically infer the holes in your Service contract from using unknown types.

But this quote doesn't have anything to do with inheritance in OrmLite where your POCOs can happily have any levels of inheritance. The issue is that you're trying to query an unknown late-bound Type where as OrmLite is a code-first ORM with a Typed API that needs access to the concrete type in order to support its Typed Expression API and populate its typed Results. My answer above includes OrmLite's limited support for untyped access.