| Summary: | Resource cannot be removed from resource set | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Egidijus Vaisnora <vaisegid> | ||||
| Component: | cdo.core | Assignee: | Victor Roldan Betancort <vroldanbet> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Eike Stepper <stepper> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | stepper | ||||
| Version: | 4.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 338921 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Egidijus Vaisnora
Created attachment 205416 [details]
Test case
Are you going to provide a test case? Argh, ignore my silly question! This bug has been introduced with the fix to bug 338921. Assigning to Vik for analysis. I believe that exception is expected. Not exactly sure about the reasons why we introduced it, but its probably related with the fact that if you remove a dirty CDOResource (in this case, a it's in state NEW), the underlying CDOTransaction is left dirty, and that may introduce unwanted changes to future commits. Performing rollback automatically is probably not safe, so I guess this exception is indicating "please tidy up your changes before discarding that resource". Eike, do you recall anything about this? Furthermore, even if that exception didn't raise, yet another would raise, because the resource doesn't exist (the resource is not committed, and neither its part of the ResourceSet, as it has been removed). So the last 3 lines of code of the test-case would fail anyway. What were you exactly trying to achieve? I remember now and agree with Vik, this is the expected behaviour. |