Re: entity inheritance possibilities
Re: entity inheritance possibilities
- Subject: Re: entity inheritance possibilities
- From: "b.bum" <email@hidden>
- Date: Mon, 8 Sep 2003 11:37:29 -0700
On Sep 8, 2003, at 11:02 AM, Ben Trumbull wrote:
Bill thinks you should just export the entire object graph to XML,
alter the schema, and then reimport it (leave the PK generation for
these objects automatic) and save it back to the database.
That would be the 100,000 foot abstracted summary....
In these kinds of situations, I have typically found it to be useful to
effectively export from the old schema and import into a new database
with the new schema. This allows you to keep a snapshot of the old
database schema in a "production ready" state while still moving
forward with the new schema; making for faster verification that all
existing features continue to work the same way.
I also find it easier to work with pure object graphs than to try and
do the conversion simultaneously at the object graph and database
level. While EO can support two separate model groups and you can use
that feature to allow for migration from one schema to another where
there is overlap between the two graphs' namespaces, it is a lot of
extra effort and not exactly a path of implementation that a lot of
people have pursued.
So, the goal is three fold:
(1) export the data in some usable format that preserves the complexly
connected nature of the object graph
(2) convert the object graph from one form to the other in a purely OO
fashion
(3) import the data into a database with the new schema and let EO take
care of PK/FK management, etc...
See the JavaWOExtensions.framework and WOExamplesHarness.framework;
they both have useful API
To dump a model, do something like this....
public static void main(String argv[]) {
System.out.println("Dumping... " + argv[0]);
System.out.println("Dumping to... " + argv[1]);
System.out.println("Dump root... " + argv[2]);
EOModel model = new EOModel(argv[0]);
String destinationDirectory = argv[1];
String dumpEntity = argv[2];
EOModelGroup.defaultGroup().addModel(model);
EOEditingContext ec = new EOEditingContext();
NSMutableSet visitedTableSet = new NSMutableSet();
String entityName;
NSArray rows;
EOFetchSpecification fetchSpec = new
EOFetchSpecification(dumpEntity, null, null);
fetchSpec.setFetchLimit(0);
fetchSpec.setIsDeep(true);
fetchSpec.setRefreshesRefetchedObjects(true);
rows = ec.objectsWithFetchSpecification(fetchSpec);
String xml = WXWebUtilities.xmlForObject(rows);
String fileName =
NSPathUtilities.stringByAppendingPathComponent(destinationDirectory,
dumpEntity + ".xml");
File outputFile = new File(fileName);
_NSStringUtilities.writeToFile(outputFile, xml);
System.out.println("\tWrote XML of length " + xml.length() + "
to " + fileName);
}
... which will result in a massive XML file being written to disk that
contains all objects accessible from the Entity specified as the first
argument on the command line. The assumption is that there is an
entity within your model from which all other entities will eventually
be accessed, even in a roundabout manner.
At this point, you'll have a very large pile of fairly complex, but
well structured, XML and will be faced with the challenge of rewriting
the XML into the new schema. While one could use something like XSLT
to do the transformation, I prefer to do the manipulation of the object
graph within a pure OO runtime. This involves reading the XML back
into an object graph.
To do this, I wrote a little Python script that parses the DOM XML tree
returned by Python's DOM parser and turns it into a pure graph of
Python dictionaries, arrays, etc... with the meta info generally
preserved (the script would need to be augmented/modified slightly, I'm
sure, as I never had the chance to throw it at quite a few graphs).
For the sake of performance, my script would write a Python pickle [a
pickle is just a binary snapshot of a graph of objects] to a file such
that I could easily read it in, mess with it, and then re-read the
pickle when I screwed up the in-memory graph...
If you want the Python script, I would be happy to send it to you (or
post it to my weblog or otherwise make it available).
Once the object graph is in memory, then it is a matter of munging it
as needed into the new form to match the new schema.
Then you would need to write it back out as XML -- I didn't do that
part in my script, but it wouldn't be hard to do [traverse object
graph, spew -- and use the JavaWOExtensions/WOExampleHarness API to
import the XML back into your data store.
Like Ben said -- it will be a pain, but is is entirely feasible. I'm
100% certain that the above is not a complete solution -- that you will
discover lots of exciting details about the conversion that I have not
encountered.
b.bum
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.