| Summary: | [Table] Remove line does not remove obsolete column | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Nicolas Guyomar <nicolas.guyomar> | ||||||
| Component: | EMF-Facet | Assignee: | Gregoire Dupe <gdupe> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | eclipse-bugzilla, gdupe, vincent.lorenzo | ||||||
| Version: | unspecified | Flags: | gdupe:
indigo+
|
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 345593 | ||||||||
| Attachments: |
|
||||||||
|
Description
Nicolas Guyomar
Of course, same problem occurs while using the "delete" command I think we should add an "isColumnObsolete()" (or "getObsoleteColumns()" ) method which would be called at the opening of a serialized table, as well as when we get notified of a model modification. Nicolas (In reply to comment #0) > In my opinion the facet should not be unloaded, so that when the user add a > element the facet is applicable to, its corresponding facet column could be > added again. +1 (In reply to comment #0) I think that the facet should not be unloaded, but the unused (facet)columns should be destroyed. Created attachment 196436 [details] Patch for Bug 346465 Hi, I have added a method in the TableInstanceCommandFactory to create a command dedicated to check whether some columns are outdated. - If a facetColumn is obsolete, then it is removed (corresponding facet is NOT unloaded) This command is appended to RemoveLine and DeleteSelectedElement's one, so that columns reappears on undo/redo There were some minors code modifications to perfom in order to prevent IndexOutOfBoundException from happening since the selectionLayer get notified while we remove columns. This scenario (delete/remove line) has to be covered by a non regression test. (a) I, Nicolas Guyomar, wrote 100% of the code I've provided. (b) I have the right to contribute the code to Eclipse. (c) I contribute the content under the EPL. (d) This contribution contains no Cryptography features. Regards, Nicolas Guyomar Created attachment 196514 [details] Patch for Bug 346465 Non regression test Hi, Please find attached a non regression test for this scenario. (a) I, Nicolas Guyomar, wrote 100% of the code I've provided. (b) I have the right to contribute the code to Eclipse. (c) I contribute the content under the EPL. (d) This contribution contains no Cryptography features. Regards, Nicolas Guyomar Hello, This bug is not blocking or critical. In conformance with the ramp down policy [1], the commit of its fixing will then be delayed to version 0.1.1 (Indigo SR1). [1] http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy Regards, Gregoire Dupe Comment on attachment 196436 [details] Patch for Bug 346465 Here is a contribution from one employee of Mia-Software, targeting future Indigo release. The company has signed a Member Commiter Agreement. The contribution does not need a CQ (see bug 322327). I've committed this contribution. Committed revision 721. Comment on attachment 196514 [details] Patch for Bug 346465 Non regression test Here is a contribution from one employee of Mia-Software, targeting future Indigo release. The company has signed a Member Commiter Agreement. The contribution does not need a CQ (see bug 322327). I've committed this contribution. Committed revision 721. This bug can be marked as resolved. This bug can be closed. |