Hello,

I am using 3.0 Final December 20th of LLBLGen Pro, and wish to map a related field in the designer that is related through a related field.

For example, my table schema is something like:

Project > Ticket > Comment.

For the Comment entity, I can map to fields in Ticket, but I would like for fields in Project to also show up in the drop down for Comment, because I know a comment can only ever be mapped to one ticket, and one ticket can only ever be mapped to one project.

I suspect it's a matter of adding a navigator or a relationship, and if so, can I get assistance with how to do this? Also, if that is what needs to be done, I would like to add it without causing a DDL to generate. In fact, I'd like to disable the designer first functionality altogether if possible.

Thanks for you help!

ISZ

Please explain why do you need this field. The usage will decide whcih way to go.

For example if you need it for databinding purposes, like showing the Project name when displaying the Comment Data, this can be done by adding a custom property in code. Which might be populated using a prefetchPath.

Hi Walaa,

I have a template I wrote that grabs all fields and adds them to a poco-like object that I use for databinding (read-only).

Example:

    public partial class <[CurrentEntityName]>MetaData : IMetaData
    {   <[Foreach PrimaryKeyEntityField ]>
        [Key]
        public <[TypeOfField]><[If GenerateAsNullableType]> ? <[EndIf]> <[EntityFieldName]> { get; set; }<[NextForeach]><[Foreach EntityField]><[If Not IsPrimaryKey]>
        public <[TypeOfField]><[If GenerateAsNullableType]> ? <[EndIf]> <[EntityFieldName]> { get; set; }<[EndIf]><[NextForeach]>
        
        //  Mapped fields on related field.<[Foreach RelatedEntityField ]>
        public <[TypeOfField]><[If GenerateAsNullableType]> ? <[EndIf]> <[MappedFieldNameRelatedField]> { get; set; }<[NextForeach]>
    }

Not pretty, but I would like to add ProjectId to the Comment.

Isn't this a very specific requirement to be used in a Template?

I'm not sure what you are asking, but I suppose yes. Nonetheless, based upon the template code I provided, values defined in the Fields mapped onto related fields tab in the designer are correctly generated. It would be convenient to allow the drop down to traverse into other 1:n tables.

I'm mainly looking for ideas on how to solve this, if possible through the tab, but if not possible, I am open to alternatives.

You mentioned custom properties, but I am not familiar.

Thanks!

Hi there. I hope to understand your situation. I would go for one of this options:

a. (easy one) Use a TypedList. In the designer create a TypedList and add the Comment, Ticket and Project entities, then add the fields you want. You then can make a poco object based on typed lists.

b. Modify your template. When you loop through the related objects, look if the related entity have also field mapped on related fields, if that happen, add then such fields to your poco object definition. It would be easier if you use .lpt template instead of TDL (limited for advance requirements).

c. If you opt for generate entities as is, and then generate your poco at runtime based on the entities, you can add a custom property as Walaa suggested. For instance:

public partial class CommentEntity
// this is a partial class of CommentEntity
{
    public int ProjectId
    {
        get 
        {
             int toReturn = 0;
             if (Ticket != null && !Ticket.IsNew)
             {
                  if (Ticket.Project != null && !Ticket.Project.IsNew)
                  {
                      toReturn = Ticket.Project.ProjectId;
                  }
             }
             return toRerurn;
        }
    }

    // ...
}

That property is ready for databinding, and ready to use for other purposes, like query it in-memory or use it to populate a DTO or POCO object.

I think option 'c' sounds like the best choice.

I'd prefer not to use a TypedList since it will deviate from conventions. Also, adding logic to the template, as described in option 'b', will cause all poco objects to be affected, rather than just the one for Comment. I would not want all poco objects to traverse related fields and traverse related fields on those related fields.

With option C, I was not clear how adding a custom property to the poco object would guarantee the property would get fetched. But from your example, I can see you've added it to the partial class of CommentEntity. My poco objects are also partial classes, so I can see now that I can create a partial poco class for the CommentMetaData object and add ProjectId as a property on it.

Thanks for helping me get clarity on the meaning behind "custom property". Originally I thought Walaa was talking about custom properties in the designer, but after re-reading I see he meant a coded solution.

I wonder if the designer could be enhanced to support the idea I am requesting about? Why couldn't the Fields mapped onto related fields tab support Comment > Ticket > Project, and so on, as long as each is 1:n?

Thoughts?