Bugzilla – Full Text Bug Listing
| Summary: | Support Visual Definition and Editing of MappedSuperclass | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] Dali JPA Tools | Reporter: | Shaun Smith <shaun.smith> | ||||||||
| Component: | Diagram Editor | Assignee: | Stefan Dimov <stefan.dimov> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dimov <stefan.dimov> | ||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | neil.hauge, petya.sabeva, sergio.e.samayoa | ||||||||
| Version: | 0.5 | Flags: | petya.sabeva:
review+
|
||||||||
| Target Milestone: | 3.2 M7 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 364004 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Shaun Smith
Shaun, are you sure this is a good idea? Wouldn't this be an overloading of the editor? Consider the following: 1. If we visualize entities along with mapped superclasses then we should visualize 'is-a' relations between them. Having both JPA relations and 'is-a' relations in one diagram would be unintuitive and confusing for the user (in my opinion) 2. Let's for example we have a mapped superclass named MS and an entity E in the diagram and let there be 3 (or more) entities named E1, E2, E3 inheriting MS. Let's now create 1-to-1 unidir relation from MS to E. The diagram should automatically show three more instances of this relation - from E1, E2 and E3. Along with the 'is-a' realtions the picture would become overloaded and confusing for the user. Perhaps there is another, more smooth way to design and implement this, but I don't see it. If we are going to introduce it we should do it carefully in order not to lose one of the main advantages of the JPA editor - its simplicity and usage easiness. Neil, what do you think? I think we need to balance diagram overload concerns with the need to visualize the entire mapping picture. Without MappedSuperclass, the mapping picture that the user is visualizing could be incomplete in many ways. I think in this case that presenting this information is more important than the concern of overload. Luckily, the diagram editor already has the very nice ability to remove elements from the diagram that the user wishes to hide. I think that with this ability the concern of overload is greatly minimized. So, in summary, I definitely think we should visualize MappedSuperclass info. That said, I don't think we need to visualize all "is-a" relationships, only those specified as MappedSuperclass Establishing a OneToOne between MS and E should not push down anything to E1, E2, or E3. This is a mapping defined on MS. Yes, E1-3 inherit this mapping but they don't define it. If I defined a basic mapping on MS I wouldn't expect to see that displayed on E1-3 either. Unfortunately, the limitation of Java source is that when looking at E1 you don't see the MS->E relationship or mapping of that relationship. The advantage of the diagram editor is that you could visually see that E1-3 inherit from MS and that MS defines a OneToOne to E. This is just like what you'd see in a UML diagram. Inheritance plays a significant roll in JPA Mapping and I believe we need the ability to visualize it. Ok, seems that we must implement it. I'm just discussing it, because I want to do it the best possible way. I'm still thinking of how and I'm open for suggestions. (In reply to comment #4) > Ok, seems that we must implement it. I'm just discussing it, because I want to > do it the best possible way. I'm still thinking of how and I'm open for > suggestions. Discussion is good. :) I'm sure we can figure out a good solution that will work well. Shaun is suggesting that inherited mappings defined on a MappedSuperclass will not be visualized on subclasses, which I think makes sense. It also reduces unnecessary diagram clutter. I assume drag and drop will simply be, drag a MappedSuperclass onto the diagram and it will appear and denote any relationships to entities already in the diagram. (In reply to comment #5) > (In reply to comment #4) I definitely don't know exactly how this is going to work either! :-) But like Neil I think we can work the details out. > ... Shaun is suggesting that inherited mappings defined on a
> MappedSuperclass will not be visualized on subclasses, which I think makes
> sense. It also reduces unnecessary diagram clutter.
> I assume drag and drop will simply be, drag a MappedSuperclass onto the diagram
> and it will appear and denote any relationships to entities already in the
> diagram ...
Since this is currently the best idea we should stick to it.
The 3.2 target now represents the Juno release. *** Bug 362417 has been marked as a duplicate of this bug. *** Created attachment 207013 [details]
Mapped superclasses visulization
This patch allows the user to create and visualize mapped superclasses and entities which inherits them. It also visualizes the 'is-a' relations. It doesn't support creation between already existing (and visualized) persistent object and deletion of an 'is-a'. I will create another bug for the latter. Created attachment 207014 [details]
This icon is part of the change submitted with the patch
Petya, please review and try the patch when you have the time. Petya, would you be able to review the patch this week? Created attachment 213179 [details]
Mapped_superclasses_visulization_v2
The original patch is reworked a little, because there was a small bug.
The patch is submitted in HEAD |