Jump to: navigation, search

Difference between revisions of "Dali/Indigo/DaliRefactoringParticipants"

< Dali‎ | Indigo
(Refactoring)
Line 1: Line 1:
=Refactoring=
+
=Refactoring Overview=
 
*Display changes in the Refactoring preview dialog
 
*Display changes in the Refactoring preview dialog
 
*Support Undo
 
*Support Undo
Line 11: Line 11:
  
  
==Refactoring Participants==
+
=Refactoring Participants=
  
===Delete Refactoring===
+
==Delete Refactoring==
  
====Java Class====
+
===Java Class===
 
*persistence.xml
 
*persistence.xml
 
**delete corresponding class element
 
**delete corresponding class element
Line 26: Line 26:
 
**Deletion of class from another project
 
**Deletion of class from another project
  
====Java Package====
+
===Java Package===
 
*all items from Java Class - multiple types will be deleted when a package is deleted
 
*all items from Java Class - multiple types will be deleted when a package is deleted
 
*package element in an orm.xml - delete it if it matches?
 
*package element in an orm.xml - delete it if it matches?
  
====Java Source Folder====
+
===Java Source Folder===
 
*all items from Java Package
 
*all items from Java Package
  
====Java Filed/Method====
+
===Java Filed/Method===
  
====Mapping File====
+
===Mapping File===
 
*persistence.xml
 
*persistence.xml
 
**delete corresponding mapping-file element
 
**delete corresponding mapping-file element
  
  
===Rename Refactoring===
+
==Rename Refactoring==
====Java Class====
+
===Java Class===
 
*persistence.xml
 
*persistence.xml
 
**udpate class element
 
**udpate class element
Line 60: Line 60:
 
**** entity/mapped-superclass cache-interceptor
 
**** entity/mapped-superclass cache-interceptor
  
====Java Package====
+
===Java Package===
 
*all items from Rename Type
 
*all items from Rename Type
 
*Mapping files
 
*Mapping files
 
**Rename package element - this can be a fragment
 
**Rename package element - this can be a fragment
  
====Java Source Folder====
+
===Java Source Folder===
  
====Java Field/Method====
+
===Java Field/Method===
 
*Java
 
*Java
 
**rename mappedBy
 
**rename mappedBy
Line 82: Line 82:
 
**update order-by
 
**update order-by
  
====Mapping File====
+
===Mapping File===
 
*persistence.xml
 
*persistence.xml
 
**update mapping-file reference
 
**update mapping-file reference
 
**Rename the default orm.xml/ecliselink-orm.xml file we could add a reference to it in the persistence.xml if it does not exist
 
**Rename the default orm.xml/ecliselink-orm.xml file we could add a reference to it in the persistence.xml if it does not exist
  
===Move Refactoring===
+
==Move Refactoring==
 
*all items from Rename Refactoring
 
*all items from Rename Refactoring
  
  
===Push Down Refactoring===
+
==Push Down Refactoring==
 
*Java  
 
*Java  
 
**Annotations move with the method/field
 
**Annotations move with the method/field
Line 101: Line 101:
 
**we would have to move the mappings to the subclass entity in orm.xml. If the subclass entity does not exist we create it.
 
**we would have to move the mappings to the subclass entity in orm.xml. If the subclass entity does not exist we create it.
  
===Pull Up Refactoring===
+
==Pull Up Refactoring==
 
*Java
 
*Java
 
**Annotations move with the method/field
 
**Annotations move with the method/field
Line 107: Line 107:
 
**Move the mapping to the superclass entity in orm.xml, creating the entity if necessary. Moving this information isn't as important for EclipseLink since it supports mapping inherited attributes.
 
**Move the mapping to the superclass entity in orm.xml, creating the entity if necessary. Moving this information isn't as important for EclipseLink since it supports mapping inherited attributes.
  
===Extract Superclass Refatoring===
+
==Extract Superclass Refatoring==
 
*
 
*
  
===Extract Class Refactoring===
+
==Extract Class Refactoring==
 
*
 
*
  
  
==JPA DB Metadata Refactoring Participants==
+
=JPA DB Metadata Refactoring Participants=
 
We need a JPA project preference for these since it would only apply for someone who is not generating their schema.
 
We need a JPA project preference for these since it would only apply for someone who is not generating their schema.
 
*Rename/Move Type
 
*Rename/Move Type
Line 131: Line 131:
  
  
==Refactoring Contributions==
+
=Refactoring Contributions=
*Move annotations to xml
+
===Move Annotations to XML===
*Move xml to annotations
+
===Move XML to Annotations===
*Change access type - move annotations from fields to properties (1 or more) or vice versa. Would have to include creating the appropriate fields or properties or choosing the ones that match.
+
===Change Access Type===
 +
*move annotations from fields to properties (1 or more) or vice versa. Would have to include creating the appropriate fields or properties or choosing the ones that match.

Revision as of 10:55, 24 June 2010

Refactoring Overview

  • Display changes in the Refactoring preview dialog
  • Support Undo
  • Any XML changes will be done without the user having to check the box 'Update fully qualified names in non-Java text files'. Currently the user can get java type renames to be completed in the persistence.xml by checking that box, but a java type delete will not edit the persistence.xml.
  • Support refactorings in 1 project affecting any JpaProject in the workspace


bug 209489

bug 136333


Refactoring Participants

Delete Refactoring

Java Class

  • persistence.xml
    • delete corresponding class element
    • A property that references the deleted class will not be deleted. The user will be left with a validation error. This is how JDT handles references to deleted classes.
  • Mappings files
    • Delete entity/embeddable/mapped-superclass element
    • Other references (id-class, map-key-class, etc) to the deleted class will not be deleted
  • Other use cases to handle:
    • Deletion of nested class
    • Deletion of class from another project

Java Package

  • all items from Java Class - multiple types will be deleted when a package is deleted
  • package element in an orm.xml - delete it if it matches?

Java Source Folder

  • all items from Java Package

Java Filed/Method

Mapping File

  • persistence.xml
    • delete corresponding mapping-file element


Rename Refactoring

Java Class

  • persistence.xml
    • udpate class element
    • EclipseLink properties - rename if the class matches
      • eclipselink.session.customizer
      • eclipselink.descriptor.customizer
      • eclipselink.logging.logger
      • eclipselink.session-event-listener
  • Mapping files
    • rename entity/embeddable/mapped-superclass class element
    • rename other class references
      • id-class element
      • element-collection map-key-class
      • 1-m/m-m map-key-class
      • EclipseLink
        • entity/mapped-superclass/embeddable customizer
        • entity class-extractor
        • entity/mapped-superclass cache-interceptor

Java Package

  • all items from Rename Type
  • Mapping files
    • Rename package element - this can be a fragment

Java Source Folder

Java Field/Method

  • Java
    • rename mappedBy
    • rename MapsId
    • rename MapKey
    • rename AttributeOverride/AssociationOverride name
    • update @OrderBy
  • Mapping files
    • rename corresponding mapping
    • rename mapped-by
    • rename maps-id
    • rename map-key
    • rename attribute-override/association-override name
    • update order-by

Mapping File

  • persistence.xml
    • update mapping-file reference
    • Rename the default orm.xml/ecliselink-orm.xml file we could add a reference to it in the persistence.xml if it does not exist

Move Refactoring

  • all items from Rename Refactoring


Push Down Refactoring

  • Java
    • Annotations move with the method/field
    • What if there are attribute overrides on the subclass for the fields that are being move?
      • Remove the attribute overrides?
      • Take that metadata and put it on the attribute? what if it is different from what already exists?
      • We can check for all of this information in the refactoring participant and decide whether there is anything we can do.
  • Mapping files
    • we would have to move the mappings to the subclass entity in orm.xml. If the subclass entity does not exist we create it.

Pull Up Refactoring

  • Java
    • Annotations move with the method/field
  • Mapping files
    • Move the mapping to the superclass entity in orm.xml, creating the entity if necessary. Moving this information isn't as important for EclipseLink since it supports mapping inherited attributes.

Extract Superclass Refatoring

Extract Class Refactoring


JPA DB Metadata Refactoring Participants

We need a JPA project preference for these since it would only apply for someone who is not generating their schema.

  • Rename/Move Type
    • Add @Table if name is not currently specified(only if it currently matches a table on the database? - would have to be connected)
      • Entity name specified - no need to add @Table
      • Inheritance SINGLE_TABLE strategy - no need to add @Table if not the root
    • Add @JoinTable if not currently specified to any relationship mappings that default to a JoinTable either owned by the renamed type or where the renamed type is the target.
    • Add @CollectionTable to an ElementCollection owned by the renamed type if it is not currently specified.
  • Rename attribute
    • Add @Column if name is not currently specified
    • Add @MapKeyColumn
    • Add @JoinColumn
    • Add @MapKeyJoinColumn
    • Add @PrimaryKeyJoinColumn
    • Add @CollectionTable if the mapping is an ElementCollection and the collection table is not currently specified


Refactoring Contributions

Move Annotations to XML

Move XML to Annotations

Change Access Type

  • move annotations from fields to properties (1 or more) or vice versa. Would have to include creating the appropriate fields or properties or choosing the ones that match.