Bugzilla – Full Text Bug Listing
| Summary: | Default values are not validated against enumerations | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] Tigerstripe | Reporter: | Yoram <yramberg> | ||||
| Component: | Core | Assignee: | Project Inbox <tigerstripe.core-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | chrhartl, nmehrega, yuri | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 0.5M0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The issue is that when refactoring Enum literals, TS doesn’t update the default values. (In reply to comment #1) > The issue is that when refactoring Enum literals, TS doesn’t update the default > values. It isn't clear to me that there's a viable in terpretation to the notion of enum refactoring. If you change AAnotherLiteral to ANOTHER_LITERAL should you use the value (1) to determine what needs to be "refactored"? I'm totally unsure about this. If both the literal and the value change, is there any way to tell? I'm totally unsure. I think that refactoring, in this case, is a manual undertaking and should not be done by the tool. The tool, however, should probably wanr us that we're about to change something that is referenced and that we need to be minded of it. *Yoram see also Validate default value literals via profile https://bugs.eclipse.org/bugs/show_bug.cgi?id=232727 For now the focus needs to be on adding default value checking to the TS auditor. We can think about refactoring enhancements later. I agree with Yoram. I don't think it's a good idea to have the tool make automatic changes when Enumeration literals change. When users change enumeration literals, users should be presented with a generic message indicating that this may affect all artifacts referencing the Enumeration and whether or not they wish to proceed. If user clicks on yes then the Enumeration should be changed and a full build should be kicked off. It's the builders responsibility to check the default values of attributes to ensure they're valid. If they're no longer valid, the corresponding artifact should be displayed with a build error. Created attachment 193146 [details]
341055 patch
Anton's patch applied. Looks great. Thank you! Closing.. |
Here's how to reproduce: Create an enumeration type 'TestEnum' and add two literals - 0 Literal 1 Another_Literal Create an entity Entity1 and add an attribute 'testEnumDefault'. The data type for this attribute is set to TestEnum. Set the default value for this attribute by pulling the choice list and clicking Another_Literal. Save everything. Now all looks fine, the attribute, the datatype the choice list and the default value. This is true for both the form editor (of the entity) and the Java encoding (of the entity). Now, edit the enum type and make changes to the existing literals - 0 LITERAL 1 ANOTHER_LITERAL Save. NOTICE: the form editor for entity Entity1 still shows the default value as Another_Literal. The choice list still shows the literals as they appeared before the change. The Java encoding for the entity has not changed. Consider: the entity is now in error as it contains a default value that is illegal (it is not a literal that exists in the enumeration type) Now, make a change in the entity (add an attribute, for example) and save. NOTICE: the form editor now shows no default value at all. The Java encoding for the entity still shows the old default value ('Another_Literal'). Consider: In fact, the entity Java encoding is now in error since it shows an illegal default value. The form editor for the entity is inconsistent with the Java encoding since it does not show any default value. ============================ What should be the correct behavior? First, the entity should be in error and the tool should warn of an illegal value in the default value item for the attribute (after the literal becomes illegal) There should NOT be any auto-refactoring in this case as the semantics of this change is not clear. *Yoram