Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Badges having same key but being applied to different node types (table vs column) overriding each other when publishing #2128

Open
mikaalanwar opened this issue Apr 4, 2023 · 5 comments
Labels
stale status:needs_reproducing For bugs that need to be reproduced in order to get fixed type:bug An unexpected problem or unintended behavior

Comments

@mikaalanwar
Copy link
Contributor

mikaalanwar commented Apr 4, 2023

Current Behaviour

In case we have two badges having the same "key" and different "category", they are over-ridden at the time of publishing based on the one that get's published last. E.g I have a table badge having "PII" and a column badge having key "PII". If I was to do something as following, it would update the category of the same badge without recognising that they are two different badges (meant for different entities).

BadgeMetadata(
    start_label=TableMetadata.TABLE_NODE_LABEL,
    start_key=TableMetadata.TABLE_KEY_FORMAT.format(
        db=table.ref.database,
        cluster=table.ref.cluster,
        schema=table.ref.schema,
        tbl=table.ref.name
	    ),
	    badges=[Badge(
                category='compliance',
                name='PII'
            )]
	)

.
.
.

BadgeMetadata(
	start_label=ColumnMetadata.COLUMN_NODE_LABEL,
	start_key=ColumnMetadata.COLUMN_KEY_FORMAT.format(
	    db=column.table_ref.database,
	    cluster=column.table_ref.cluster,
	    schema=column.table_ref.schema,
	    tbl=column.table_ref.name,
	    col=column.name
	    ),
	    badges=[Badge(
                category='column',
                name='PII'
            )]
	)

Expected Behaviour

Ideally, the uniqueness check of badges should also consider the category or the type of the node / entity (column vs table) it is being applied to. Otherwise, column badges could override table badges and vice versa etc.

Possible Solution

The workaround that I am currently considering to use is to use a different/unique name of table or column badge but doesn't seem ideal.

Steps to Reproduce

  1. Try creating badges using the pseudo-code above.
  2. The order of creating will determine which category gets applied.

Screenshots (if appropriate)

image

Context

Yes, we have a scenario where we have a table and a column badge having the same name. A change in ordering of badge creation (during some refactoring) caused the relevant "table" badge to disappear from the home page as they category of that badge was changed from "compliance" to "column" (and we don't display column badges on our home screen).

Your Environment

@mikaalanwar mikaalanwar added status:needs_triage For all issues that need to be processed type:bug An unexpected problem or unintended behavior labels Apr 4, 2023
@allisonsuarez
Copy link
Contributor

This was the intended behavior of badges, similar to how if you name 2 tables exactly the same thing they would be considered the same table. You can try naming the table and column badges slightly differently in the database and for display purposes you can configure the badges to display any string even if its the same.

@MrwanBaghdad
Copy link
Contributor

@allisonsuarez In the badge case they're not the "same" as they're categorically different for column badge and table badge. Our initial thought was that the "category" should be included in the de-dedup and should be enough to differentiate the badges. similarly, if we have tables of the same name with different storage layer i.e (Redshift or Bigquery)

@B-T-D B-T-D added status:needs_reproducing For bugs that need to be reproduced in order to get fixed and removed status:needs_triage For all issues that need to be processed labels Apr 14, 2023
@stale
Copy link

stale bot commented May 3, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label May 3, 2023
@stale
Copy link

stale bot commented Jun 10, 2023

This issue has been automatically closed for inactivity. If you still wish to make these changes, please open a new pull request or reopen this one.

@stale stale bot closed this as completed Jun 10, 2023
@Golodhros Golodhros reopened this Jul 7, 2023
@stale stale bot removed the stale label Jul 7, 2023
@Golodhros Golodhros added stale and removed stale labels Jul 7, 2023
@stale
Copy link

stale bot commented Aug 7, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale status:needs_reproducing For bugs that need to be reproduced in order to get fixed type:bug An unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

5 participants