Id Column

I have one table that has an primary key column set manually

property Id from Entity<T> is readonly

how do I set this value?

Is the scenario that your table uses a piece of business data as the key (e.g. a People table that uses a social security number as the key)?  If so we do not currently support this structure: the LightSpeed convention is that keys should be pure handles.  The recommended way of resolving business-data keys or composite keys is to use a surrogate key with one of the standard IdentityMethod strategies that LightSpeed can use as the internal ID.

If you have an existing database and can't add a surrogate key, let us know a bit more about your scenario and we will see whether it can be addressed. 

If the manually-set PK is not a piece of business data, could you say a bit more about the requirement to set it manually -- why is the exact value significant?  We can then look at ways to support that requirement.  Thanks!

  I have several situations where the key was a important unique field that is assignable by the customer.

like purcahse order number. the type column in a type of material database. etc..

I have already switched my tables to support the convention

I can easily live without this feature if you allow (Feature Request) associations on unique keys and not just primary keys

Do you definitely need the association to be on the business data field e.g. the PO number?  If your PurchaseOrders table has an internal ID and a PurchaseOrderReference (assignable by the customer), and an OrderLine has a PurchaseOrder reference, is it not possible for the OrderLine.PurchaseOrderId column to be the internal ID rather than the reference?  Put another way, why does the join -- which is a purely internal operation -- have to be on the business data column rather than the key?  You still end up with the same relationships either way...

Obviously if you are working with pre-existing schemas then the association may have to be on the business data field, but if you have control over the DB schema then my feeling is that performing the association on the business data probably won't be necessary.

(Just to be clear, we're not ruling out doing the unique key association, just trying to establish what the scenario is for it.)

I am writting a material tracking/inventory softare.

When a Detailer is drawing a project sizes of material may change. I have a MType table to keep track of all the information of a type of material. Then I have a sizes table that tracks all the available sizes. Then I have a parts table that is the material entered for a project. I was hoping to just set the type field in the MType table as primary key so I could have a relation set up between the type field in my parts and type field in my MType. so when the type changed in a Part the MType was easier to look up (hopefully automatic by Lightspeed with eager load to avoid round trips)

There are many workarounds. Like having a typeID column and whe

All this could be solved by doing associations on unique keys and not just primary keys. But what are the chances of that happening since I dont know of an ORM that provides this functionality not even LINQ to SQL or the EntityFramework(not 100% sure but havent found it yet). The problem is determening if unique keys are a single column or not which opens up a can of worms.

LightSpeed will perform the MType lookup automatically even if you use an internal key: typically, we would expect changes to the Part's MType to be accomplished by setting Part.MType rather than Part.MTypeId.  And (as you note) with eager loading you can ensure that the MType gets loaded in the same database query.  So the efficiency of querying for a Part and inspecting its type "name" is only slightly impacted by using an internal key.  As far as behaviour is concerned, there should be no difference between using the "meaningful data" key and the internal key.  (Obviously there is a difference if someone looks at the underlying relational data -- then they would see the customer-defined name of the material right there in the Parts table instead of the internal key -- which I can see might be helpful for debugging or diagnostics, but that could also be handled by a view.)

Enabling associations on unique keys is an attractive idea, and we could close the can of worms by decreeing that the LightSpeed convention is that a unique key must be a single column (same as we decree that the primary key must be a single column).  However, since the critical behaviour can be achieved by using an internal key and eager-loading for performance, we will probably not be implementing this immediately unless we identify further scenarios where it would be useful.  Thanks for the suggestion though!