Community
Participate
Working Groups
Diagram's entities should reflect the changes done through code editor. Adding and removing fields seems to work. However, when entity is renamed, it totally disappears from the diagram. I suppose there would be some event/hook to catch on and update the diagram, when such JDT renaming occurs. Steps to reproduce: 1. Install Eclipse Helios (build 20100617-1415). Install Graphiti nightly build (0.7.0.v20100827-0726). Install JPA Diagram Editor (0.5.0.201008131407). 2. Create new JPA project. Select <None> target runtime, minimal JPA 1.0 configuration, Generic 1.0 platform. I used EclipseLink 2.1.0 user library for JPA implementation. Everything else default. 3. Open JPA Diagram. 4. Create an entity and drag-drop it into diagram. Save the diagram. 5. Refactor entity by selecting it in the Project Explorer and pressing F2, give the entity a new name. 6. The entity disappears from the diagram.
This is one of the limitations of the JPA diagram editor and I'm afraid it cannot be fixed, because the problem lies down in the Eclipse resource model. Of course the JPA Editor uses resource model listeners. The problem is that when the user refactors a certain entity through JDT we get two events - the first one is for deleting the entity resource and the second one is for creating a new resource. There is no way to know if the user is renaming or deleting/creating entities. When the user triggers the rename operation through the JPA editor it has a workaround which allows proper behavior of the editor, because it "knows" that such operation was triggered ... We should include this limitation in the proper section in the project wiki page ...
This is unfortunate. One hack around this would be to store some details from the deleted entity and if a new one is created with the same details within a certain time limit (1 second, 10 seconds?), JPA diagram could interpret that as a rename instead. I don't know what sort of data could should be collected, properties and their types perhaps? Yeah, it's messy. Do you consider it too messy?
How about check for table name? I mean change in entity name might still retain the same table association.
Well, until now we've considered it too messy to fix it with our resources. (Two people only, including me.) Perhaps some day we'll find time for this. But there is an option here. Now, that we've contributed the editor, we welcome anyone who wishes to contribute some fixes and/or enhancements ...
(In reply to comment #3) > How about check for table name? I mean change in entity name might still retain > the same table association. You now, table name is not mandatory in the annotations ...
*** Bug 338946 has been marked as a duplicate of this bug. ***
I just happened upon this bug and wanted to suggest how you can fix it. I am reopening it. You can be a refactoring pariticpant. This is what Dali does to handle refactoring a class and updating the corresponding orm.xml or persistence.xml. Take a look at the following extension points for more information: org.eclipse.ltk.core.refactoring.deleteParticipants org.eclipse.ltk.core.refactoring.moveParticipants org.eclipse.ltk.core.refactoring.renameParticipants org.eclipse.ltk.core.refactoring.copyParticipants org.eclipse.ltk.core.refactoring.createParticipants
I see Petya is already working on this via another bug. Marking the older bug as duplicate *** This bug has been marked as a duplicate of bug 395460 ***
The issue is reopened for further investigation, as desribed in comment #5 in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=395460
Retargeting this bug for Kepler 3.3 RC1. Seems that this bug is important, since a deadlock occurs when renaming an entity which has a bi-directional relationship. I believe fixing this bug will avoid the deadlock also.
As discussed with Neil in the mail, the change is too big and I don't feel confident to submit it in this late phase of the Eclipse Kepler release. So I am opening a separate bug only for the deadlock: Bug 409090 and re-targeting this one for Eclipse Kepler SR1.
Retargeting for Kepler SR2.
