Multi-tier Migration

You are viewing an old version (v. 5) of this page.
The latest version is v. 22, last edited on Feb 11, 2010 (view differences | )
<< View previous version | view page history | view next version >>

Continue with version "0" of the Task class defined in Getting Started chapter:

package example;

public class Task {
        public boolean prioritized;
}

Now we have class CompileTask subclassing from Task class as below:

package example;

import java.util.List;

public class CompileTask extends Task {
        public List<String> srcFiles;
}

Instance of CompileTask can be serialized to XML with XMT as below:

package example;

import java.util.ArrayList;

import com.pmease.commons.xmt.VersionedDocument;

public class Test {
	public static void main(String args[]) {
		CompileTask task = new CompileTask();
		task.prioritized = true;
		task.srcFiles = new ArrayList<String>();
		task.srcFiles.add("Class1.java");
		task.srcFiles.add("Class2.java");
		String xml = VersionedDocument.fromBean(task).toXML();
                writeXMLToFileOrDatabase(xml);
	}
}

The resulting XML will be:

<example.CompileTask version="0.0">
  <prioritized>true</prioritized>
  <srcFiles>
    <string>Class1.java</string>
    <string>Class2.java</string>
  </srcFiles>
</example.CompileTask>

Pay attention to version attribute of the root element: XMT examines the class hierarchy (except for class java.lang.Object) to get current version of each class, and concatenates them with period. Since there are no migrate methods defined in class Task and CompileTask, current version of both classes are of "0", and the resulting version of the hierarchy (or composite version) will be "0.0".
When deserializing the compile task object from XML, XMT splits this composite version to get XML version for each class in the hierarchy, and repeats the process described in Getting Started chapter for each of these classes. So if class Task is evolved to take numeric priority value described in Getting Started chapter, we simply add migrate methods in Task class, while keeping CompileTask intacted. If we continue to evolve class CompileTask to include a compile option field with default value "-debug", the migrate method will be defined in CompileTask like below:

package example;

import java.util.List;

public class CompileTask extends Task {
        public List<String> srcFiles;
        public String options = "-debug";
        
        @SuppressWarnings("noused")
        
}
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.