PATCH: Major refactoring updates to class name functions

Okay, here it is ... I have totally refactored the entire set of class, field, property, variable, et-al. naming functions.  This is a very, very large patch (~450KB) that touches a huge number of files.  This patch does a few things (all to svn rev 563):

It eliminates the multitude of class name formatting functions that were accepting strings as input parameters.  It centralizes all the class name formatting functionality and uses recursion to properly reuse formatting.  It only exposes signatures that take in Schema objects, so you get a much more consistent result.  For example:

GetStructName(SourceTable.Name) becomes GetClassName(SourceTable, ClassNameFormat.Struct)
GetAbstractClassName(SourceTable.Name) becomes GetClassName(SourceTable, ClassNameFormat.Abstract)

There are also two new properties on the template.  One allows you to specify one or more table suffixes to remove from the table names (just like the table prefix, but from the other end of the name).  The other allows you to specify if you are using an alias file, a mapping.config file or nothing.  This way, people that have an alias file and a mapping file can be sure they know where their information is coming from.  In the event that you specify alias or mapping files, if it doesn't find a match for a specific item (entity or column), it will recursivly call itself and create a name as if you were not using any file at all (just for that item).  This property defaults to None, so if you are used to using a mapping.config or alias file, be sure to set this property explicitly before you run your generation.

On the topic of mapping.config files: I added two new attributes (PropertyName and FieldName) to both Table and View nodes.  These are created automatically if you are generating from scratch, but if you are using an existing mapping.config file, you'll need to add these attributes yourself (or generate a new mapping.config).

This patch currently generates compiling code that works with my DB and with Northwind.  I have no need for and have not tested the web application or admin projects.  They compile, that's all I can say.

This patch generates code properly from scratch.  I do not promise that it will generate code that is compatible with create-once files generated by previous versions of NetTiers.  If you find places where this is true (that it doesn't work), please try to post specifics here and I will investigate as I am able.  Please don't bother posting if you can't be specific about the discrepency, the template in which it's a problem, etc.  As Jerry McGuire said, "Help me, help you."

Finally, a lot of the comment blocks are wrong.  I did a lot of copy-paste work on some of them and didn't keep up with the summary and param tags.  I need to clean that up at some point.

Please take a look, give it a run, let me know what you think.  NT Team, please do the same.  Let me know what, if anything, I need to address in order to accomplish getting this committed to the trunk.

Tony

 

Hi tselke:

So far its a great patch but just noticed something wich its maybe related wich the changes.

In every GetByIX  procedure of my Providers classes I am getting a wrong SP parameter casing wich produces a SQL error on my db.

For example:

I have a Category table and a corresponding GetByCategoryId method in my SqlCategoryProviderBase class. So far so good the problem is that the SP parameter is declared in this method as idCategory but the wrapper defines it as @IdCategory (Notice the casing diff in the ID) wich makes the underlaying ExecuteReader method to throw an exception cause the IdCategory param isnt defined.

TBH i didnt checked the code in depth to check if this is an error related to your patch or not. I will check this later and post my findings. Just posting this to let you know/check if this issue could be related or not.

Best regards and great work !!  

Thanks for the feedback and compliment. 

This is almost certainly a result of my changes.  Are you running the patch-generated classes against pre-patch stored procedures or are the stored procedures from the patched build also?  My guess is that the T-SQL is being created with the function GetFieldName() and the GetByIX is passing parameters that are from GetPropertyName().  The question is whether the patch is internally inconsistent and I didn't catch it because my DB is not case sensetive or the patch is internally correct, but not the same as previous builds.

Tony

Hi:

I was checking the templates a little more and found a mismatch in the code that generates the procedures and the one that creates the EntityProviderBase classes.

Looks like you forgot to update the GetByIndex Functions to use the refactored GetPropertyName because the line 854 of SqlEntityProviderBase.generated.cst is using the GetFieldName as you mentioned.

After modifying that line to use the GetPropertyName function the template started to generate the correct sp parameter value. :D

So, i guess thats just it... :D 

I will keep testing it and let you know if i find anything else.

 

Best regards 

 

PS: I just checked the GenericEntityProviderBase.generated.cst template and it has the correct function call to GetPropertyName, so i guess the only one with this problem is the SQL one. Didnt checked anything else, cuz i am not sure if the webservice code use something like that, or another provider type, so maybe its a good idea to check for it... :D 

Hi Tony,

Good work, although I have some problems with it...

1. Generation report no longer display in IE (v6 or v7)

2. When I generated against Northwind the class name and subclass for some Views is incorrect in the custom partial class. eg:

View: 'Customer and Suppliers by City'

Abstract "CustomersAndSuppliersByCityBase.generated.cs" class:

public abstract partial class CustomerAndSuppliersByCityBase - this is correct

Custom "CustomersAndSuppliersByCity.cs" class:

public partial class CustomerandSuppliersbyCity : CustomerandSuppliersbyCityBase - incorrect case of "and" and "by"???

3. Casing of ID type columns doesn't seem correct. eg:

MySpecialID becomes MySpecialid - the ID is incorrectly lowered

 

Keep up the good work! 

hth

swin

This makes no sense.  The function calls to get the class and abstract class names in the templates EntityView.cst and EntityViewBase.generated.cst are identicle.

EntityView.cst

string className = GetClassName(SourceView);
string abstractClassName = GetClassName(SourceView, ClassNameFormat.Abstract);
public partial class <%=className%> : <%=abstractClassName%>

EntityViewBase.generated.cst

string abstractClassName = GetClassName(SourceView, ClassNameFormat.Abstract); 
string className = GetClassName(SourceView); 
public abstract partial class <%=abstractClassName%>

I wonder, are you certain that you do not have an older mapping.config or alias file that has names that were generated by a previous build?  Or, perhaps the patch didn't update both templates correctly?

Tony

I'm sure I did a completely clean gen, but I'll do it again when if I get a chance later.

I'll check the templates to see if they match the above.

swin 

Yes No. 2 is ok, not sure what was going on there but it seems ok now.

However 1 & 3 still stand.

hth

swin

I fixed the outstanding issues and this patch has now been commited as SVN570.

thanks

 

swin 

Custom stored procedures does not work after this patch, please fix...

Can you be somewhat more specific?  It doesn't find them at all?  It doesn't create the proper function wrapper names for them?  It doesn't create the proper SQL to call them? Maybe you have an example of what is wrong and you can explain what you expected?  Ideally, you might have actually investigated the templates themselves and you can point out where you think the issue may be found?

By making it easy for the community to help you, you greatly increase the odds that you will be helped and you greatly reduce the amount of time that it is likely to take for your help to materialize.

Tony

Alex/Tony,

This occurred because of a change in the SqlEntityProviderBase.generated.cst file where the name of the custom proc is outputted.

I've reverted the code to pre-572 i.e. use GetSafeName rather than GetPropertyName

Fixed in SVN573

hth

swin

Thanks, but there are more problems with this patch, particulary with Pascal casing. I have columns with ID at the end and they all are generated in code as Id and my code does not work anymore... How I can fix this?

That's not a mistake.  That's Pascal casing.  Swin went through a lot of effort to make that work right.

The fact that is doesn't match your existing property names is a separate issue.

Tony

I had the same problem when all of this casing stuff started changing around the mid-550s. I haven't been able to use the nightly build since then, but have been manually applying a lot of the patches since they address other critical things I've run into (deepload recursion).

Unfortunately, I started this project before I had seen the MS naming conventions (http://msdn2.microsoft.com/en-us/library/ms229043(VS.80).aspx), and since most of my code is VB.NET, I'm not too conscious the details of casing standards. When I first checked the NetTiers docs, I didn't realize that the naming specs were actually "SHALL" rather than "SHOULD", and didn't realize how important it is until I was 6 months in. So I now have the same ID/id/Id kind of problem in my field names that Tony describes. The MS tools are generally case insensitive once a table is created, so I haven't been able to (easily) fix the field names.

The latest builds have a new tri-state for mapping/alias/none. Would it be feasable to have a fourth state which does NO casing/processing of field names? This kind of option may be important for those of us putting NT into an existing poorly-named codebase.

Thoughts anyone? Is this a big job (touches more than commonsqlcode.cs), or could a noob like me figure out the relevant patches to the current release?

-Jim