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.

Sign up for GitHub

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

Jump to bottom

Edit domain forgets settings for categorical variables when values change in any way #6660

Closed
markotoplak opened this issue Nov 30, 2023 · 3 comments · Fixed by #6776
Closed

Edit domain forgets settings for categorical variables when values change in any way #6660

markotoplak opened this issue Nov 30, 2023 · 3 comments · Fixed by #6776
Assignees
@markotoplak
Labels
bug A bug confirmed by the core team meal This will take a day or two

Comments

@markotoplak
Copy link
Member

What's wrong?
Edit domain is very picky about values. As soon as a set of values changes, it forgets all settings connected with that variable. The widget even forgets about

This seems to be the issue of #6659. In #6415 we fixed widget so that it uses schema-only hints instead of contexts, so I was surprised by #6659. Indeed our handling if categorical variable is very strict.

How can we reproduce the problem?

  1. Take a data set with a categorical variable. Edit its name in Edit domain. Save the workflow.
  2. Add a value into the data set. Reload workflow. Notice that rename is lost.
  3. Remove the added value. Reload workflow. Notice that it is renamed again.

This behavior does make sense, because stored hints look like this after playing:

{('Categorical', ('iris', ('Iris-setosa', 'Iris-versicolor', 'Iris-virginica'), ())): [('Rename', ('blabla',))],
 ('Categorical', ('iris', ('Iris-setosa', 'Iris-setosa1', 'Iris-versicolor', 'Iris-virginica'), ())): [('CategoriesMapping', ([('Iris-setosa', 'Iris-setosa'), ('Iris-setosa1', 'Iris-setosa-ki-jo-pobrisem'), ('Iris-versicolor', 'Iris-versicolor'), ('Iris-virginica', 'Iris-virginica2')],))]}

Each categorical variable is matched with name and all values. Is this too strict? Should we leave it like this or can we do anything else? This smells of contexts. :)
@markotoplak markotoplak added bug A bug confirmed by the core team needs discussion Core developers need to discuss the issue labels Nov 30, 2023
@markotoplak markotoplak mentioned this issue Nov 30, 2023
Closed
@janezd
Copy link
Contributor

janezd commented Nov 30, 2023

I would say that any applicable hint should be reused. Adding values should be acceptable. Perhaps even renaming values that no longer exist - it's just a hint after all, so if a renamed value is removed, it won't be renamed and that's it.

To me it doesn't smell of contexts. :) There, the problem was that different contexts matched, and we couldn't define a rule that would work in all cases. Here, it's just about the strictness of matching or, actually, about treating hints as loosely as possible.

@markotoplak
Copy link
Member Author

So I guess we can say then: apply as many transformations as possible if type and name match (remove values in var descriptions).

@janezd
Copy link
Contributor

janezd commented Nov 30, 2023

Oui.

@janezd janezd added meal This will take a day or two and removed needs discussion Core developers need to discuss the issue labels Dec 1, 2023
@ales-erjavec ales-erjavec mentioned this issue Mar 29, 2024
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@markotoplak markotoplak

Labels
bug A bug confirmed by the core team meal This will take a day or two
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[FIX] Edit Domain: Partial restore state on categories mismatch ales-erjavec/orange3
2 participants
@markotoplak @janezd