Is there any way to see:

1. Which entities' tables have unique constraints defined on them?
2. The entity fields that represent the columns that make up the unique constraint?

For example, I have a customer table with a UC on customer_name. I would like to be able to see that the CustomerEntity has one unique constraint, and that constraint contains one field (CustomerFields.CustomerName).

Is there any way of extracting this information? If it's not built in, is there any way of getting it using reflection (I could retrieve it once and store it at application startup).

I'm trying to do something that is similar to what I posted in the thread below, but automatic based on what's in the database/entity:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=14476

Thanks,

Phil

Best way is to generate this with a small template, as it's not present in the generated code as retrievable info (the unique constraints only show up as special methods)

There are simple TDL statements to get this data: for each entity, then foreach unique constraint, and you can then loop over the fields, and forexample emit code which builds up a dictionary or hashset.

You can also write an .lpt template, each EntityDefinition contains a property (which is a sortedlist) which contains ArrayList objects with entity fields, each arraylist is a unique constraint.

Yes, that datastructure isn't .net 2.0-ish but it does its job

Thanks Frans.

This may seem like an unrelated question, but will code generation and template modification still be as relevant in 3.0 as it is in 2.6?

I ask because I don't want to invest in learning Template Studio if it's not going to be useful to me in a few months.

Phil

v3 has templatestudio integrated, so you can always edit templates, alter templatebindings files etc.

If the templates used are not of your liking, you still have to alter the templates, that's pretty trivial. However v3 has a flexible system to define attributes, interfaces and namespaces to entities (and attributes to all other elements for example, like fields), using macros, so you can define a lot more in the designer so if you needed template changes for that, you don't have to.

Also, all settings for code generation and frameworks in general is xml based now (the definitions of the settings And the values (values end up in the xml project file)). So it's easy to add custom settings to a framework which show up in the designer (e.g for a field, navigator etc.) and which can be utilized in the code generator. The generated code is now more controllable as you can exclude features you don't want (e.g. remoting) and you can also use this system for custom templates you write your own (so no more dreaded custom properties (which are still there btw) for controlling code gen ).

The project inner model is completely different, so people using .lpt templates will have some porting to do. I think it's easier to write code to the model now as the model is easier to access, and more utility methods are available in the project. As we use .lpt templates for nhibernate/ef/linqtosql templates, we are adding all kinds of methods (if they're not already there) to make writing templates consuming meta-data easier.