tonysneed
commented
5 years ago @Vizehase I apologize for having missed your question. While it might be possible for me to add something like an EF IModel to the template data that surfaces in the Handlebars context, it would probably bloat the context and slow down the model generation.
A more powerful and flexible approach would be to create a class that inherits from HbsCSharpDbContextGenerator and override the GenerateOnModelCreating method, which has an IModel parameter with access to all the model metadata. What I would need to do is change the visibility of the _templateData and other members from private to protected.
What do you think about this approach?
Vizehase
I have just written Handlebar Helpers in order to place our own naming conventions (we have some special prefixes in DB names for tables and columns I don't want to see in the entities) and for including some converters for properties of a special data type, i.e. we use a DB data type named "Boolean" which is in fact a char(1) containing 'N' for false and 'J' for true (the German Ja/Nein for yes/no). So I installed a Handlebar Helper for the properties template which detected the [Column(TypeName = "Boolean")] attribute and changed the property's type from string to bool. That worked well so far. But I also have to add code to the context's OnModelCreating method such as entity.HasConversion(GBoolean.Instance). Here I am off because from the "property" Handlebar Helper's method where I detected the attribute and changed the property type I had no access to the helper class that sees the OnModelCreating code. Because the entities are touched after the DbContext class I could not use global variables to store that info between the calls of the two helper methods.
One way to help here would be to add the entities and properties/attributes info to the entity Handlebars context. This would also help me with including some code to OnModelCreating that places a HasQueryFilter call to every entity containing a field for soft delete.