m-kovalsky / modelautobuild Goto Github PK

If a calculated column is such that the DAX code generates a quoted string it will not be removed by the ModelAutoBuild.cs file.
The ModelAutoBuildExample.xlsx works because the one calculated column is a simple SUM without anything that would generate a quoted string. But as soon as I create a Calculated Column such as a PATH(id, parent_Id) or a CALCULATE as soon as the comma is added it generates a quoted string.

The current code only removes the quotes from the measures.

One workaround I am using is to remove the quotes in the same else block that creates the Calculated Column. Or else I would need to do it similar to the Measure code and iterate through each Calculated Column.
Note: I know the best method is to not create calculated columns and push that down to the database layer

With the new version of Tabular Editor 2.13.0 the FormatDax method has been deprecated.
https://docs.tabulareditor.com/FormatDax.html
This is in an effort to reduce the workload on the Dax Formatter site.
The proposed solution is to use alternative syntax such as FormatDax(Model.AllMeasures); so that it is done in a single request.

When enabling DAX Formatting in the Model Auto Build with the new Tabular Editor it does generate this message:

Script warning: This script is making multiple calls to the "FormatDax" method, which has been deprecated! Calls will be throttled to not overload the DaxFormatter.com service. To avoid throttling, please change your script to use the FormatDax extension method going forward. For more information, see: https://docs.tabulareditor.com/FormatDax.html

The C# script does not support the Model Permission of Refresh and ReadRefresh. Unless this is to enforce best practices it would be helpful to have these permissions.

As a workaround, I have added it manually to the script file.

Do you have plans to extend this to include Calculation Groups? Would love to see this feature.

It is present for columns but not for measures.

BTW The way the code is written makes this project so extensible. If it fits my client's needs I could add more types like Decimal_OnePlace and Decimal_TwoPlace depending on how many decimal places they wanted to see by default.

There currently was an existing Dimension named ServiceRouteMaster related to ServiceRouteMasterId in the current model.

For testing purposes I created a test column in the Fact Table named TestServiceRouteMasterId and another dimension table with the name of TestServiceRouteMaster. When I went to build this I got error messages about ambiguous paths. After creating some debug outputs I was able to determine that for the new dimension table it was getting the correct column from the fact table TransactionLines.TestServiceRouteMasterId but for the dimension it was using ServiceRouteMaster.ServiceRouteMasterId.

I determined this was due to it matching the same EndsWith pattern since it read the original ServiceRouteMaster column first.

var dim = Model.Tables.FirstOrDefault(t => factColumn.Name.EndsWith(t.Name + keySuffix));

If I switch it to use Equals(t.Name + keySuffix)); it builds the correct relationship.

Could see this happening if someone had Location and CustLocation or StoreLocation.

I have not made the jump to v1.4. Waiting for time to test.

Can you still run the process from the command line without pasting the script in Tabular Editor?

I currently use a Powershell script to automate the build and deploy process.