sne wrote:
Thanks, found it.
However, when trying to use it I get a compilation error. Maybe I'm wrong but is it supposed to also work in .lpt files (as opposed to .template files)?
No, TDL is a simple DSL language which uses .template files and which is interpreted. .lpt files are not using TDL nor an interpreter, they're used to generate code which is then compiled and run and which produces the output.
So <[]> statements are TDL statements and which are not mixable with plain C# code in a .lpt file. I think Walaa overlooked that.
To do what you want, you have to know whether a subtype is mapped onto the table at hand. The code below isn't tested, but you should get an idea what to do.
The template is included into createscript.lpt or updatescript.lpt. This means that some variables are local to the script code. I'll assume you're using it for createscript.lpt
The project the template is used on is in the variable _currentProject. The template is included at line 127 of createscript.lpt. This shows that the current table is in the variable table.
Now, to do this efficiently, I think it's best if you add this code to the Createscript.lpt file (a copy of course, bound in a custom templatebindings file), below line 7, so in that code block:
var allEntityMappingsPerTarget = _currentProject.GetAllMappedEntitiesPerTarget(_executingGenerator.DriverID);
This is now available in the createtableinclude template. DBTable implements IProjectElementMapTargetElement, so you can do in createtableinclude:
var entitiesMapped = allEntityMappingsPerTarget.GetValues(table, true);
and then check on whether a subtype is mapped
if(!entitiesMapped.Any(e=>e.IsSubType))
{
// not a subtype. You can check for other things, like inheritance hierarchy type as well.
// Check the designer reference manual for details
}
Btw, adding extra columns might cause extra fields being added when you refresh the catalog, so if you don't do that, you're fine, otherwise you have to take that into account.
I've changed/extended the code generation templates because there are several properties (columns) that I would like to have generated automatically, without having to add them to nearly every entity in the LLBLGen designer. That is, they are needed for tables where inheritance isn't used and where it is, only in the root table (I'm using Target per Entity).
Right now they are generated for every single table.