Extended Field Feature Request

Would like to see if it would be possible to add a feature that allows access to columns in a table that are not defined as fields in the entity.

Say I have a table called Specifications and want to give users the ability to add new columns for Volts, Watts or whatever else they may need to define.  Adding the column on the database side is a snap, but at that point the property will only be available in code if the model is syncronized and rebuilt.

Would be nice to see an entity property LoadExtendedProperties or something of the sort that when enabled on an entity will cause it to load an entire data record into the entity.  This would be great for tables where the structure may change based on some dynamic business requirement.  

Scenerio Code (Note this is just me thinking out load here.. :):

First I would enable loading of extended properties on Specifications entity similar to the way you define eager loading scenarios (actually entegrating this with eager load strategies would be awesome)..

Then use the folowing to get at an extended/dynamic data value/property that is dynamically defined by an end user.

var specifications = (from sp in Specifications

select sp).ToList();

foreach(Specification spec in specifications) {

Console.WriteLine(spec.ExtendedProperties["Watts"].ToString()); // or could do by index spec.ExtendedProperties[0].ToString()

}

In in the above code you could define the initial entity in the desinger, and then set the entity property to load the extended properties.

When LS makes a query for the entity data it would issue a query similar to below rather than a strongly typed one.

SELECT Specifications.* FROM Specifications

Also if this entity is being eager loaded by a parent entity liek a Products entity it would look like this.

SELECT  Products.PartNumber,

Products.Description,

Products.Dicontinued,

Specifications.*

FROM Products

INNER JOIN Specifications ON

Products.PartNumber = Specifications.PartNumber

Since the Products entity is not set to load extended properties, the resulting query would strongly type the resulting SQL query, but the Specifications table would pull all columns.

I have looked into some of the blogs that show how to use Dynamic objects and other options for this scenario, but for situations such as this it would be nice to not need to Dynamically modify the Entity design.  The Dynamic option does not allow me to entegrate other business entities created with LS either through the designer or code.  So if you have a products entity in standard LS code that you would like to relate to the specifications table it's a no go, since the dynamic versions are not compatable.

Any thoughts?

We don't plan to implement this within LightSpeed as it would require some major rework: LightSpeed is built around a core of knowing that the entity fields are, and it would be a big rewrite to handle dictionary-like property bags.  However, we may be able to offer some guidance on ways to accomplish this at the app level, or on alternative approaches, or we may be able to identify a simpler feature that would enable your use case without requiring the big rewrite.

So perhaps you could say a bit more about your use case.  It sounds like you will have to do a recompile anyway to use a new extended property (e.g. to write ExtendedProperties["MyNewColumn"]), so why not just do a database sync?  That would make the new code you had to write shorter and clearer (.MyNewColumn instead of .ExtendedProperties["MyNewColumn"]) and of course would give you compile time safety.

My guess for this would be to use some hybrid of static and dynamic behaviour, e.g. a static base class or interface which gets extended with extra fields at runtime based on a config file or database schema to create a derived class containing the desired extended fields.  The main problem will be handling associations as you will want those to instantiate the extended derived class, which currently requires a discriminator: however, adding 'automatic' inheritance would be easier than adding a property bag.