Dali/Indigo/DaliRefactoringParticipants

From Eclipsepedia

< Dali‎ | Indigo
Revision as of 12:58, 14 October 2010 by Paul.fullbright.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

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 1 or more JpaProjects in the workspace
  • Must handle other refactoring participants making changes to the same files. The assumption will be that we are the only ones making changes for JPA spec metadata. So while other refactoring participants can change the same file, they must not make the exact same changes as Dali.

Phase 1

bug 209489 - Participate in Java type level refactorings

bug 318028 - Participate in mapping file refactorings

Delete: Java class, Java package, folder, mapping file

Rename: Java class, Java package, folder, mapping file

Move: Java class, Java package, folder, mapping file

Phase 2

bug 318174 - Participate in Java field/method refactorings

Phase 3

bug 138622 - Convert annotated JPA metadata to orm.xml

bug 265344 - Change access type

Refactoring Contributions

Phase 4

bug 136333 - Participate in Java refactoring to change JPA DB metadata

JPA Metadata

Phase 5

Push down, Pull up, Extract superclass, Extract class

Refactoring Participants

Delete Refactoring

Delete 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
      • If there are multiple type mappings that reference the deleted java class (an error case) then delete all of them.
    • Other references to the deleted class (id-class, map-key-class, etc) will not be deleted
  • Other use cases to handle:
    • Deletion of mapped nested class. Also deletion of top-level class that includes a nested class.
    • Deletion of class from another project
    • If deleted classes are not listed in any persistence.xml or orm.xml make sure the 'Delete classes referenced in JPA metadata files' node does not appear in the preview tree


These screen shots show a refactoring preview dialog where Foo.java and Bar.java are deleted. There were listed in the persistence.xml, orm.xml, and eclipselink-orm.xml files. The other refactorings will follow the same pattern with the one composite change that contains a change for each affected file.

persistence.xml preview changes of deleted java classes orm.xml preview changes of deleted java classes

Delete Java Package

  • all items from Java Class - multiple types will be deleted when a package is deleted
  • package element in an orm.xml
    • for now we will not touch the package element even it it matches exactly. In order to delete the package element we would have to check all types - entity, mapped superclass, idclass, target-entity, etc. Handle with validation bug 193535.

Delete Folder - Source or Other

  • all items from Java Package above
  • persistence.xml
    • delete corresponding mapping-file elements

Delete Java Field/Method

Do we want to do anything? At least lower priority

  • Java files
    • delete attribute/association overrides that reference the deleted field/method
  • Mappings files
    • delete corresponding attribute mappings
    • delete attribute/association overrides that reference the deleted field/method

Delete Mapping File

  • persistence.xml
    • delete corresponding mapping-file element

Rename Refactoring

If 'Update references' is *not* checked on the refactoring dialog then the following changes will not be made.

If 'Update fully qualified names in non-Java text files' is checked we must not conflict with the platform making changes. If it is unchecked our changes will still be made as long as 'Update references' is checked.

Rename Java Class

  • persistence.xml
    • udpate class element
    • EclipseLink properties - rename if the class matches
      • eclipselink.session.customizer
      • eclipselink.exception-handler
      • eclipselink.logging.logger
      • eclipselink.session-event-listener
  • Mapping file
    • rename entity/embeddable/mapped-superclass class element
    • rename other class references
      • id-class element
      • 1-1/1-m/m-1/m-m target-entity
      • element-collection
        • map-key-class
        • target-class
      • 1-m/m-m map-key-class
      • EclipseLink
        • entity/mapped-superclass/embeddable customizer
        • entity class-extractor (not yet supported - bug 297531)
        • entity/mapped-superclass cache-interceptor (not yet supported - bug 319321)
        • all converter type classes on entity-mappings, entity, mapped-superclass, embeddable, id, basic, version, element collection

Rename Java Package

  • all items from Rename Type
    • If the referenced type is partially qualified it will be fully qualified after the refactoring
  • Mapping files
    • Rename package element if it is an exact match to the renamed package

Rename Folder

  • persistence.xml
    • update mapping-file reference
    • update jar-file reference - we have decided not to update the jar-file reference. The java class path is not updated when a jar-file is removed, so we will just let the user update the reference as appropriate once they have updated the classpath.

Rename Java Field/Method

'Update similarly named variables and methods' - Rename Type - this is technically part of the refactor Rename Java Class, but we will support it here.

  • 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
    • rename pre-persist, post-persist, pre-remove, post-remove, pre-update, post-update, post-load

Rename Mapping File

  • persistence.xml
    • update mapping-file reference
    • Rename the default orm.xml/ecliselink-orm.xml file and add a reference to it in the persistence.xml if it does not exist. If it is renamed back to the default name the reference will not be removed from the persistence.xml.

Move Refactoring

  • all items from Rename Refactoring above
    • except Move Package. A package can only be moved to another source folder either in the same project or another project. This will not affect the referenced location of the package either in a persistence.xml or orm.xml file.

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 moved?
      • 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

bug 136333

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

bug 138622

Move XML to Annotations

Move XML to XML

  • Move an XML entity to another mapping file

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.

bug 265344

Rename Sequence/Table Generator

  • rename the generated-value->generator references in java and orm.xml