Handling Default Values

I'm new to LightSpeed, and currently evaluating it for use within our company. We used to use EntitySpaces, but as it's no longer maintained we need to find a replacement as we use ORM quite heavily.

I have found that when I create a new record, any fields that I don't give a value will end up being NULL in the database, even though all fields have a default value in the database. I've spent a few hours digging through forum posts, etc. and what I have found seems to be that LightSpeed doesn't care about the default value in the database. Am I missing something, or is this still the case? I'm really puzzled why an ORM system such as LightSpeed doesn't care to use the default values already assigned in the database. I have come across some "work-arounds" that involve a constructor that sets a default value, but that is a truly hopeless approach because what happens when you create new fields in your database down the road? You would have to go back and update ALL your existing applications that use those tables to include the default values for any new fields. That won't work.

Please tell me there's a solution to this issue. If not, I really don't see how anyone could use LightSpeed for anything related to a database. Even our former ORM, EntitySpaces, used the default values in the database when creating new records.

I'd be really interested in finding a solution to this as well, but it is a really complicated issue. How did EntitySpaces handle it? Did they set the default values in the constructor or just not generate the SQL for the insert statement? Did you have to do anything special when setting or changing a default value? Entity Framework shares this limitation.

I don't recall how they did it exactly. I've never had to change a default value once in production.

Why isn't there an option to not commit any fields with empty values, this way the database can assign the default values and everyone is happy. How hard would that be to implement?

No thats right, default values handling should be done as part of the constructor logic for the entity rather than as part of the database, although you might have defined in both places due to other applications inserting data where they would need to use those default values.

In terms of why, LightSpeed is entity centric so the database is primarily treated as a persistence store. The database is intended to reflect the state of the entity in memory at the time it was persisted. We dont have an option to commit a field with an empty value because the field does actually already have a value (the value currently assigned).

A couple of examples of this might be:

• If we have an entity with two properties, one of which is an Int32 with a default value of 42 in the database, when I create the entity what value does it have? If I have not assigned anything it will be the default value for the data type which is 0. When saving changes we intend to persist the state of all entities involved in the scope of the UnitOfWork, so the value needs to reflect what was available to the other entities within the unit of work scope, e.g. 0.

• If I create a new entity and then have it created based on a SaveChanges call but have not completed the scope of the unit of work is the value 0 (default) or has it magically updated to 42 (default value from the database). Are associated entities notified of this change? If so why is there a difference between this change and a change made by user code? If not how do they appreciate that a difference has occurred (e.g. UI needs to be refreshed)?

We are certainly open to considering any reasonable change if you want to raise a feature request around this outlining how this might work in practice.

Jeremy

The solution is very simple: Say we have an entity named Customer, with 3 properties: FirstName, LastName and Email. If I create a new Customer entity, and only assign values to FirstName and LastName, LightSpeed should only commit those 2 fields to the database for the new record. This way the database can use the default values already in the database to populate any fields that aren't committed by LightSpeed. There could simply be an option in the UnitOfWork for this behavior, so it can be enabled on the fly when needed, so it would still be backwards compatible.

What is the value of Email from the perspective of another object prior to calling SaveChanges? Maybe a default value gets assigned on access similar to a lazy load but it remains unassigned otherwise?

We dont currently have the notion of an "unassigned" field in LightSpeed so while the above sounds simple in concept its not currently possible for us to express this and because of this Email does have a value so we need to persist that. Ill pop this on the feature requests backlog for us to consider in the future but we are not currently intending to make any changes for this.

Jeremy

Jeremy, it seems to me that we are looking at this very differently. To us, the database is the center of the universe, not the ORM system. We maintain a lot of backend systems, the largest one has over 40 subsystems accessing and sharing tables in the same database, and only some of them are using ORM for data access.

Back to the example. If I retrieve an entity from the database, LightSpeed is tracking which properties I change, and will only commit properties that have been changed. Why can't it do the same when creating a new entity? If a property on a new entity hasn't been set or changed, don't commit that property to the database. The functionality is already there for existing entities, so why isn't it possible to use the same approach for new entities? It doesn't matter what value an unassigned property may or may not have. If I don't assign a value in code to a certain property, in other words if I don't touch a property on a new entity, that property should not be committed when saving the new entity.

I understand this all comes down to how you are applying LightSpeed and ORM, which can be done in many different ways, however there are so many systems out there where your approach of the database just being a persistence store simply doesn't apply.

Indeed, LightSpeed is a framework for rapidly building persistant domain models, its the domain model which is at the center of the universe, the database is a persistance store. If you want the database at the center of the universe then LightSpeed is not going to be as flexible in this regard as just using raw ADO.NET because we are always thinking in terms of .NET objects and the domain.

In terms of the change tracking example, I think we are largely thinking the same thing here, the existing change tracking functionality isn't going to solve this problem though. We would need additional smarts to represent the concept of an undefined value (which should be initialised to a default value if it were ever accessed). As I mentioned earlier Ive added this to our backlog for future review.

Jeremy