Relationships - Custom logic

Hi,

I am trying to add a relationship between two classes but the primary key column & foreign key column in the db are zero padded to different lenghts. In the primary table it is 15 chars long and the foreign table it is 10 chars long. I am not allowed to modify the DB since it's used by a legacy application which might break.

What's the best way to associate these two classes?

I added a property to contain the un-padded version:

public string Recipe_code
{
	get { return this.Id.Substring(0,10); }
}

Can I refer my entity relationthip to point t this property instead of the default "Id" property? Or is there a better way of dong this?

Thanks,

I think you may have two options here, but you will need to have a play to see if they fit specifically.

The first option would be to set your Id property to field generation only, and then implement the Id property in a partial class with your custom logic. This would seem to be the simplest approach unless you actually need the Id property to be full length in some scenarios (not entirely clear if that matters for your case above).

If it does, and you need to have a seperate property then have a look to see if using the "Key Property Reference" will cover this - see this post for more details. You will need to add a settor to that property to allow it to pass through any updated assignment, but otherwise this should work ok.

Jeremy

Thanks for the reply.

Just to clarify:

"implement the Id property in a partial class" : by this do you mean create a struct and set the Id to this type?

and how does one set a property to field generation only? can this be done via the designer?

You need to set the property to field generation via the designer (I am assuming you probably are), however if you are not using the designer for code generation then just implement this in your class directly. By partial class I am meaning the actual entity class as the code generation from the designer emits a partial class allowing you to implement any custom logic in a seperate class file.

e.g. if your entity is called Member, then create a Member.cs and implement it as

namespace <namespace of your model>

{

public partial class Member

{

<any new code such as your manual implementation of the Id property would go in here>

}

}

For implementing the property itself, copy the existing definition to your partial class and then modify it as per your original property definition to perform the string truncation logic.

Jeremy

I just need to jump in here as I am not sure that Jeremy's solutions will work.  When LightSpeed wires up or resolves a foreign key it does so on the FK field and the Id.  I think you won't be able to use Key Property Reference because this has to refer to a real persistent field, not a CLR wrapper property (it is intended for scenarios where the FK field must be unconventionally named or is part of a composite key); and you can't set the Id to field generation only because we don't provide access to the Id field.

I think what you may need to solve this is a custom association resolver.  This basically allows you to override the query that LightSpeed issues to resolve an association (e.g. when you call Widget.Recipe), and also to customise the foreign key value that gets set when you set an association (e.g. when you set Widget.Recipe = someRecipe). See the IAssociationResolver interface and AssociationResolverAttribute class.

In your case the GetQueryExpression at the end containing the foreign key would return a query for the padded code, something along the lines of:

string padded = "00000" + ((Widget)sourceEntity)._recipeCode;

return Entity.Attribute("Id") == padded;

And SetForeignKey would set the FK field to the un-padded code:

((Widget)childEntity)._recipeCode = ((string)parentId).Substring(0, 10);

At the end containing the collection, things would be a bit different. GetQueryExpression would get a collection of objects whose FKs matched the unpadded Id:

return Entity.Attribute("RecipeCode") == this.Id.Substring(0, 10);

And SetForeignKey would do nothing because there is no FK field at this end of the association.

See http://www.mindscapehq.com/forums/Post.aspx?ThreadID=2653&PostID=11412 for details though these are spelled out in the context of a different scenario.  Note also that there are significant limitations when using custom association resolvers, particularly in certain cascade delete scenarios.

Obviously Key Property Reference is a lot simpler than this if you can get it to work but I am a bit doubtful and hopefully this will give you something to fall back on if it doesn't!