I have an entity A that references User entity. The field that references it is called AssigneeId. The property on entity A is called User.

Now I add another reference to User entity via a field called UpdatedById. What do I get? I get a property on entity A called User_. A hopelessly ambiguously named property.

Why is the adapter template doing this? Why not call it UpdatedByIdRef or UpdatedByIdInstance. Anything is better than EntityName_ or EntityName__ or better yet EntityName___.

This underscore's rule theology appears in other spots as well like PrefetchPaths. Its nuts. I dont see the justification for it.

Respect to Frans and all the awesome work he's done, but this issue seems a gaping pothole in the gold brick road of quality that LLBL is.

Related Fields, prefetchPaths...etc are by default named after the referenced entity. And the underscore is used by default to prevent name clashes.

But you are encouraged to change those names from the LLBLGen Pro Designer. ("Fields on relations" sub-tab).

I would agree with the original poster's comment as I know LLBLGen does have the information/metadata available to create a slightly better first pass naming attempt.

I prefer to do as few manual changes to the LLBLGen project file as possible, not because I don't trust it but it forces everyone in our team to have to document all the changes somewhere since we can't easily compare different revisions of the project file.

As soon as you have a large project in LLBLGen (>100 tables) or if you start using LLBLGen in a project of this size having a sane default for field names is definetly helpful, despite how easy/hard it is to rename the fields on relations.

Tim

Ok, I didn't realise you had control over it. I guess its not all bad. But it's not all good.

Have you guys checked the 'FieldMappedOn... patterns in the project properties? You can create what you want today with macros right in a pattern for name creation.

It's already build in . If you need more macro's for the patterns, let me know. (so topicstarter should use a pattern like {$EndEntityName}Using{$EndEntityFieldNames} for example

You can preset these for every project in the preferences, so they're inherited with each new project.

Otis wrote:

Have you guys checked the 'FieldMappedOn... patterns in the project properties? You can create what you want today with macros right in a pattern for name creation.

It's already build in . If you need more macro's for the patterns, let me know. (so topicstarter should use a pattern like {$EndEntityName}Using{$EndEntityFieldNames} for example

You can preset these for every project in the preferences, so they're inherited with each new project.

Is there a convenient way to strip the "Id" or "_Id" off the end of {$EndEntityFieldNames}?

mikeg22 wrote:

Otis wrote:

Have you guys checked the 'FieldMappedOn... patterns in the project properties? You can create what you want today with macros right in a pattern for name creation.

It's already build in . If you need more macro's for the patterns, let me know. (so topicstarter should use a pattern like {$EndEntityName}Using{$EndEntityFieldNames} for example

You can preset these for every project in the preferences, so they're inherited with each new project.

Is there a convenient way to strip the "Id" or "_Id" off the end of {$EndEntityFieldNames}?

You want a part of a field's name? That's currently not possible, you then need to run a plugin you write (which is very easy though) to make that happen.

Otis wrote:

mikeg22 wrote:

Otis wrote:

Have you guys checked the 'FieldMappedOn... patterns in the project properties? You can create what you want today with macros right in a pattern for name creation.

It's already build in . If you need more macro's for the patterns, let me know. (so topicstarter should use a pattern like {$EndEntityName}Using{$EndEntityFieldNames} for example

You can preset these for every project in the preferences, so they're inherited with each new project.

Is there a convenient way to strip the "Id" or "_Id" off the end of {$EndEntityFieldNames}?

You want a part of a field's name? That's currently not possible, you then need to run a plugin you write (which is very easy though) to make that happen.

Yes, so if a CarEntity has an Owner_Id field (which points to a Person table), the resolved foreign key would be CarEntity.Owner.

I'll look into making a plugin...whats the best place to start?

Please check the SDK which comes with documentation of plug-ins and the sourcecode for all the plugins of LLBLGen Pro to get you started.

The SDK ref manual contains the api documentation of the object model available to you through the project object.

Cool bananas.

Mike heres a func i use in my templates for cleaning up names.

public static string GetFriendlyName(string name){
    Regex exp = new Regex("(\\w)([A-Z])"),
        idExp = new Regex("(\\w)Id$");
        
    if (idExp.IsMatch(name))
        return exp.Replace(idExp.Replace(name, "$1"), "$1 $2");
    
    return exp.Replace(name, "$1 $2");
}

It puts spaces between PascalCasedNames and drops off Id from the end (if it's there). Otis that FieldMappedOn sounds good (maybe change the default?), pothole repaired

worldspawn wrote:

Cool bananas.

Mike heres a func i use in my templates for cleaning up names.

public static string GetFriendlyName(string name){
    Regex exp = new Regex("(\\w)([A-Z])"),
        idExp = new Regex("(\\w)Id$");
        
    if (idExp.IsMatch(name))
        return exp.Replace(idExp.Replace(name, "$1"), "$1 $2");
    
    return exp.Replace(name, "$1 $2");
}

It puts spaces between PascalCasedNames and drops off Id from the end (if it's there). Otis that FieldMappedOn sounds good (maybe change the default?), pothole repaired

Great, thanks