Ned, First, thanks for your interest and generous reply. Your use of XSL to translate version 1 to version 2 sounds like the way to go. Do you think there is any place in the Castor architecture where we can build in support for these type of issues? For example, wouldn't it be cool if you could set something in the unmarshaller to take XSL information and translate the XML to version 2, and THEN do the unmarshall? I'm not sure if this is practical or not, but it would be nice since I know the "legacy" issue has bitten everyone at least once. What do you think?
thanks, Bob. -----Original Message----- From: Ned Wolpert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 3:28 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] using castor for data import from XML into DB On Wed, 2002-01-23 at 10:44, Robert Ollila wrote: > 1. The object model must be designed in a relational database type of model > in order to later use JDO. For example, each class should have some ID type > field, and the cardinality of the relationships may have to be defined from > several perspectives within the java classes. In other words, objects > contained within objects may need to have references to the objects that > contain them depending on your database schema. I wouldn't normally do this > if I was not going to use JDO. So, the bottom line is that JDO support can > not just come as an afterthought for ANY object model - the XML schema you > use must be designed accordingly. Any input on this ? In this specific case I'm not using a legacy database, so I don't have this specific issue. However, in most of my Java apps, I tend to have an object model that is different than my database model in some ways. The mapping file can be easily modified to account for changes in my database without affecting my object model. However, for this situation, you have to build the object model based on the database schema. I don't have a good way to do it that makes it easy to manipulate on your end. However, the best idea is to take an ER diagram of your schema, open up and XML schema tool (Like Tibco's) and create the schema using that technique to compare the two. The best would be to have a tool to read the database schema and generate an XML schema, but I know of none that do that. (For me, I'd write the XML schema by hand based on database schema, and manually manipulate it only because I haven't seen a good set of tools to do this for me.) > 2. How do you plan to handle future legacy issues with the data that is > produced? For instance, if version 1.0 of your product creates XML > instances on a users system, what happens when version 2.0 comes out and you > have changed the XML Schema and object model (maybe you added some new > fields). Will you be able to read the old XML files with the new object > model? The same question goes for the database, will you be able to read > older objects from the database? I guess this is more of a general Castor > issue though. But I am pretty concerned about it. My solution for now is > to require that any new fields added to an older schema must be "optional" > so that you don't get validation exceptions when you try to unmarshal an > older XML instance with the newer java class. That's kind of kludgy though. > Any suggestions? This has bit me in that past, and will bite me later on, that's for sure. There are many work-arounds, but no good solution. Some people attach version numbers to tables/tags. Some provide import tools for the old database, and XSL/t to translate XML from version 1 to version 2 (which is what I do) and others just start from scratch and write adapters each time. (Which is the usual corporate solution I've found in some companies I worked for) For my solution, on the root node of the XML file, keep a version number. Write style-sheets that can translate from version 1 to version 2 and use them as a pre-processor routine. If you're database can handle multiple 'versions' then you're really lucky. Else, you'll have an epoch event to do an upgrade in your production environment. Another possible solution is you leave version 1 the way it is, and write version 2 to refer to version 1... sorta like OO-style apps, where you are inheriting from the previous version. Nah... that's too silly. ;-) Let me know what you end up doing. I love these architectural problems. -- Virtually, Ned Wolpert <[EMAIL PROTECTED]> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
