Do you have a way to designate the natural key fields?

For many of my tables, we have an ID field, and Natural Keys. NHibernate allows you to map Natural Keys and ID fields.

The ability to designate the natural keys in the program would help. Otherwise, I will have to manually modify hundreds of mapping files.

For An Example take the following class part.

The _agencyIndexis the ID field and _agencyNameis the Natural Key.

public partial class Agency
{
    private System.Decimal _agencyIndex;
    private System.String _agencyName;

Also, do you have an option to use AutoProperties?
Like This:

    public virtual System.Decimal AgencyIndex { get; set; }

Instead of:

    public virtual System.Decimal AgencyIndex
    { 
        get { return _agencyIndex; }
        set { _agencyIndex = value; }
    }

michael_a wrote:

Do you have a way to designate the natural key fields?

No. The PK is the PK and that's the info that is kept and used during entity operations.

michael_a wrote:

For many of my tables, we have an ID field, and Natural Keys. NHibernate allows you to map Natural Keys and ID fields.

The ability to designate the natural keys in the program would help. Otherwise, I will have to manually modify hundreds of mapping files.

How does this 'Mapping' work on NH? Maybe you can mimic such behavior using the LLBLGen extension facilities (partial classes, inheritance, templates, custom settings, sdk, etc).

michael_a wrote:

Also, do you have an option to use AutoProperties?
Like This:

    public virtual System.Decimal AgencyIndex { get; set; }

No. The field's approach is used, as there is a lot of other parts of the system that depends on this, even the new entity materialization performance features. But, What would you gain using auto-properties?

Natural keys are an alternative to surrogate keys, i.e. SSN over a sequenced ID. You have both, so I think with Natural keys you mean a non-PK unique element which is usually created using a unique constraint. Am I correct in this assumption?

If so, you can define unique constraints on the entities in the entity editor. You can't use these for relationships (so you can't use them as the PK side of a relationship) but you can use them in fetching.

Otis wrote:

Natural keys are an alternative to surrogate keys, i.e. SSN over a sequenced ID. You have both, so I think with Natural keys you mean a non-PK unique element which is usually created using a unique constraint. Am I correct in this assumption?

If so, you can define unique constraints on the entities in the entity editor. You can't use these for relationships (so you can't use them as the PK side of a relationship) but you can use them in fetching.

Yes, you are correct in this. I was looking for a way to mark the constraint or "Natural Key" in the tool, and generate the correct mapping code. I guess this tool will not fit my needs.

I am not sure how you can use a constraint to help you fetch a row in a database, could you please explain that more? I know that if there happens to be indexes on these fields, that will help, but not sure how the constraint helps fetch rows. Aren't constraints for helping make sure that you don't save duplicate rows and validate data before it is saved?

daelmo wrote:

Maybe you can mimic such behavior using the LLBLGen extension facilities (partial classes, inheritance, templates, custom settings, sdk, etc).

I bet I could make something work with modifying templates, or extensions or something, but I was looking for something simpler

daelmo wrote:

No. The field's approach is used, as there is a lot of other parts of the system that depends on this, even the new entity materialization performance features. But, What would you gain using auto-properties?

The auto-properties would result in cleaner looking code, that's all. How does having the private fields etc, help with the materialization performance features?

michael_a wrote:

Otis wrote:

Natural keys are an alternative to surrogate keys, i.e. SSN over a sequenced ID. You have both, so I think with Natural keys you mean a non-PK unique element which is usually created using a unique constraint. Am I correct in this assumption?

If so, you can define unique constraints on the entities in the entity editor. You can't use these for relationships (so you can't use them as the PK side of a relationship) but you can use them in fetching.

Yes, you are correct in this. I was looking for a way to mark the constraint or "Natural Key" in the tool, and generate the correct mapping code. I guess this tool will not fit my needs.

What target framework are you using? (i.e. LLBLGen runtime, NHibernate, EntityFramwork)

michael_a wrote:

I am not sure how you can use a constraint to help you fetch a row in a database, could you please explain that more? I know that if there happens to be indexes on these fields, that will help, but not sure how the constraint helps fetch rows. Aren't constraints for helping make sure that you don't save duplicate rows and validate data before it is saved?

If you are using LLBLGen runtime as the target framework, it will emit routines to fetch entities based on PK and also fetch routines based on unique constraints. So, it's useful in your case to generate code that is ready to fetch objects based on natural keys (if they are defined as unique constraints).