Default values for non-existing columns in model? - (urgent!)

Hello there ninjaz!

I have a question about the mapping process I guess?

Is there any way in some setting to enable default values to properties if the corresponding column in the database does not exist?

We have an environment with many databases with different names, but the same table name and we´re accessing data through Lightspeed just fine. However! This is only OK when the tables differ only in certain ways, for example if there are more columns than in the model it´s OK, but if there are less columns than needed for the model mapping process, an exception occurrs, something like:

Unknown column 'databasename.columnname' in 'field list'.

To clarify, what I´m asking is this:

If I in my model have an entity with 3 attributes A, B and C, can I in some way if column B would happen to not exists in the database, not break the model, but just put null in the property or a default value?

Please, is there any way to circumvent this?

Best regards, Johan

I guess by looking at the method:

protected TField Get(ref TField field, string propertyName)

I could derive from Entity and "new" over the Get something like:

    protected new TField Get<TField>(ref TField field, string propertyName)
    {
        try
        {
            /* Try to get the value in a normal way */
            return base.Get(ref field, propertyName);
        }
        catch
        {
            /* If it fails, assign the field the default value (or maybe null would be better?)*/
            field = default(TField);
        }

        return field;
    }

you could set field to default(T) and return it if the propertyName did not correspond to any column in the table?

Haha, I don´t really know what I´m doing here :)

Please help.

Thanks in advance!

This is not easily possible, because LightSpeed normally loads all the fields in one go, and composes the SQL query based on all the fields of the entity.

The only way I can think of to work around this is to abuse the lazy loading feature. That is, mark the 'optional' columns as part of a named aggregate: this will cause LightSpeed to skip them during initial entity load. They will instead be loaded on demand which means you can catch the exception from Get as you have already figured out. (For efficiency, if you know that the column exists in the current database, you can pass the aggregate name as part of the query, so that the field gets eager loaded. This avoids n+1 problems.)

However, this works only for loading! If you try to save such an entity, LightSpeed will still try to write out all the fields. You might be able to work around this for updates using unversioned partial updates, but that won't help for inserts (we'll try to write out all the fields, because we have no way of knowing that the database is missing columns). So really you can only do what you want if your entities are read-only. If you need to be able to read and write to variable schemas, you will need different entity types, maybe with a common interface or using concrete table inheritance or something:

interface IWidget { int A { get; } int B { get; } int C { get; } }
partial class FullWidget : IWidget { }  // all members implemented by LightSpeed
partial class BLessWidget : IWidget { public int B { get { return 0; } }  // A and C implemented by LightSpeed

There's no really elegant solution though I'm afraid.

Thanks for answering!

We will actually not write to any of the databases using Lightspeed, so I guess I could use your method (if I figure out how to :P)

In the meantime, I started working on using dynamic objects with dynamic linq.

Since you seem to actually be experts on these kinds of things, if you have some time over some day, could you please take a look at this thread: http://stackoverflow.com/questions/8995161/is-it-possible-to-use-dynamic-objects-with-dynamic-linq

I would appreciate it very much!

Thanks!

I haven't done enough with Dynamic LINQ to answer that question, but I wouldn't be optimistic -- obviously you can return the results of a query into dynamic, but I think you'd still need to provide a strong-typed IQueryable to query over.

You can however do something similar with LightSpeed using dynamic entities (http://www.mindscapehq.com/blog/index.php/2011/04/19/defining-lightspeed-entities-at-run-time-part-1/) and query objects. It's not tremendously pretty but it should be reasonably easy to hide behind a facade -- but it would mean you'd have to know at run-time whether the database has missing columns or not, before configuring the dynamic entities. (The idea being that you'd create your dynamic entities to have LightSpeed fields only for the columns that exist, and defaulted properties for the columns that don't.)

For more help on the lazy load solution, see http://www.mindscapehq.com/documentation/lightspeed/Performance-and-Tuning/Controlling-How-Entity-Data-Loads and http://www.mindscapehq.com/documentation/lightspeed/Performance-and-Tuning/Understanding-Named-Aggregates.