Using Table.AddKey to define a primary key doesn't create the constraint for unique values

[pade]

I have been using the Table.AddKey function in Power Query to define primary and foregin keys using both Power BI Desktop and Power BI Dataflows. After getting more lines than expected after a merge based on columns having the keys defined I understod that creating a primary key, e.g.

Table.AddKey(Table, {"BK1", "BK2"}, true)

there is no check that the combinations of BK1 and BK2 are unique i the table. Defining a primary key on a column combination that is not unique shall generate a runtime error, or am I wrong? If not, what is then the differense in using true/false as the third argument. I.E. in the query below, the ID is not unique and there shall be a runtime error generated

let
    tableType = type table [Id = Int32.Type, Name = text],
    table = Table.FromRecords({
        [Id = 1, Name = "Hello There"],
        [Id = 1, Name = "Good Bye"]
    }),
    resultTable = Table.AddKey(table, {"Id"}, true)
in
    resultTable

[v-qiuyu-msft]

Hi @pade, 

I will report this issue soon internally. 

Best Regards,
Qiuyun Yu 

[v-qiuyu-msft]

Hi @pade, 

I have reported this issue internally: CRI 188079227. Will update here once I get any information. 

Best Regards,
Qiuyun Yu 

[v-qiuyu-msft]

Hi @pade, 

I got information that "It's by design. It's just metadata, we don't do any verification of it".

Best Regards,
Qiuyun Yu

[pade]

@v-qiuyu-msft Does this mean that there is absolutely no difference if I set the second parameter to true or false?
I guess there are intentions for the feature with the second parameter and that Microsoft just didn't design the Table.AddKey function with a second argument for just metadata, and with new features coming to Power BI Dataflow with a Relationship DB backen, I guess having a primary key will be more important

[v-chuncz-msft]

@pade 

It seems only Table.Keys returns different results. If necessary, you may create a support ticket to consult more.