Nullable Id's?

Hi! I'm a bit qurious if you could add support for an entitybase with nullable Id's? //Daniel

No, LightSpeed does not support this.  Every entity must have an ID, and we have no plans to relax this requirement.

Could you say more about what you're trying to achieve?  Is this a legacy scenario where an existing database contains NULL IDs?

Event though ID is a data-context concern I might want to look at it in code and (even though there exists entitystate etc) check if a value has been assigned. I then think it's better to make use of the a generic-nullable Id that has been constrained to a struct. This since I think a test for HasValue or comparision against null is much more clearer than e.g "id > 0". //Daniel

Fair comment, and from the point of view of nullable/non-nullable semantics I agree with you, but in practice there are big difficulties with this idealised approach.

The problem is that we can't represent all "not yet assigned" Ids as null.  We need every entity to have a distinct Id, and all nulls are the same.  Why do we need the distinct Id?  Internally, the Id is how we locate entities in the identity map, so changing this would require major rework.  But even externally, in the public API, we need distinct IDs so we can wire up associations.  Consider what would happen if we did allow entities to have null IDs for "id not yet assigned." Suppose we had created some Orders, but their IDs had not yet been assigned (e.g. because we were using the IdentityColumn identity method.)  Now what would happen if you set orderLine.OrderId = null?  Which of the null-Id Orders would the OrderLine be assigned to?  Or would it be assigned to no Order at all?  How would you represent a nullable association if null were a valid value for the FK field because the associated entity might have a null ID?

So we still need to allocate distinct IDs, even if only temporary ones, so that you can use them in FK fields -- we can't just leave them all as null.  Of course you can argue that FK fields are an implementation detail and people should be setting object references (orderLine.Order = someOrder), which doesn't depend on the Id, but in practice people sometimes do want to use the FK fields, and again removing them would be a major rework for us.

Therefore, rather than using null, what we need is a way to identify that an ID has not yet been assigned (or, rather, that the assigned ID is not permanent).  We could provide a separate flag for this, but a simpler option would be to add an extension method to Entity:

public static bool HasId(this Entity<int> entity) {
  return entity.Id > 0;
}

if (someEntity.HasId()) {
  // ...
}

I think that would probably meet your requirement of not polluting application code with the id > 0 test, without the complexities of requiring us to support nullable IDs and distinguish between entities with the same null ID.

Hi! In the order case.... This is an data-context ID that LightSpeed uses and shouldn't be made visible. Under the hood you could use an X-Id that You use for relations etc. The Id that actually is persisted should be made visible via the Id-property. When an entity has been persisted, these values will of course be the same. //Daniel