I think that I could do that.
On Fri, 2002-11-22 at 12:09, Martin Poeschl wrote: > could you please write it in xdoc format? > i think it would be important to have a migration howto added to the site > > martin > > Quinton McCombs wrote: > > >I have recently migrated to T2.2RC1 from T2.1. I decided to use the > >decoupled torque. > > > >Here is a short list of what I went through to complete the migration > >(not actually completed). I will post a more detailed message sometime > >over the next week or so. > > > >1. Imports need to be changed. I think that everyone understand this > >one. > > > >2. Dealing with transactions and obtaining/releasing database > >connections. > > All references to TurbineDB and DBConnection must be changed. There > >were only a few place in my application where I needed to obtain a > >DBConnection object. It was usually for transaction control. > > To make this work with the decoupled torque, I used > >o.a.torque.util.Transaction and o.a.torque.Torque. Check the javadocs > >and you should easily understand how to correctly use them. > > > >3. Abstract classes & torque. > > I had several classes persisting to the same database tables in version > >2.1. The new version of torque defines an abstract method called copy() > >which will return a copy of the object for you. This must be defined in > >you classes which extend whatever base class represents the table. This > >is going to be really easy... Torque will define a copyInto() method > >for you in the base class. Your implementation just needs to call that > >method passing a new instance of the sub class. > > > >4. Primary keys are no longer instances of ObjectKey. > > This may have been my second biggest headache. Torque will now > >generate your classes to use int or Integer (depending upon the setting > >of javaType and defaultJavaType in xxx-schema.xml). That is also > >assuming that you used numbers for your primary keys. > > > >5. Torque generated TurbineUser and other Turbine related tables. > > To stop this from happening rename you turbine-schema.xml file to > >turbine-schema.xml.nogenerate (or anything else for that matter). It > >did not do any harm to generate these files but it poses a problem if > >you reference TurbineUser (or similar object) in your .om classes and > >forget to import the correct version. > > > >6. Extending turbine user > > My application had a very minor extension to TurbineUser. However, > >this is where I spent the most time during the migration. The fact that > >torque generated the Turbine related tables made me think that life was > >going to be much easier in this release. As I started down the road of > >making changes to turbine-schema.xml to make my extensions, I started to > >realize what a mistake I had made. > > Using Henning's DB security service seemed to be an easy answer. > >However, in the end, I could never make it work. My final road block on > >this path was the fact that TemplateSessionValidator would put an > >instance of o.a.t.om.security.TurbineUser into the session. Granted, I > >could have rewritten the validator... It was also going to be a pain > >because RunData expects the User object to implement > >o.a.t.om.security.User. There are also still a few places where (like > >TemplateSessionValidator) where o.a.t.services.TurbineSecurityService is > >still coupled. > > In the end, I went the route of extending via the old 2.1 method. Some > >changes had to be made to get this to work with the new version but it > >was MUCH easier that the first approach that I took. > > > >7. Scheduled jobs - still in progress > > Right now I simply turned off the job scheduler. It threw an exception > >during startup as soon as it tried to load the first job from the > >database tables. I have not looked at this at all. > > > >8. XMLRPC - still in progress > > Right now it is turned off. I hope that I don't run into any problems > >with it. > > > >9. Logging > > It appears that you need to be using Log4J for your logging if you want > >any toque messages. This should also hold true for fulcrum if you > >decide to use it. > > I have actually found that I like Log4J much better than whatever the > >default was in 2.1. It took a little while to figure out how to get the > >settings configured correctly but after that, no problems. > > > >10. Configuring Torque.properties > > It took me a little while to figure out how to get those settings > >correct to work with Oracle. I finally found a posting on the mailing > >list that showed the setting to configure the dsfactory. Without those > >settings, torque threw an exception started the ID broker. > > > > > >Well, like I said, that is the short version. I will try to get more > >detail broken into several postings. Hopefully, by the time I am ready, > >Wiki will be ready for use and I will just put it there. > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >Quinton McCombs< Strategic Planner, NEqualsOne 1800 International Park Drive Suite 205 Birmingham, AL 35243 p: 205.324.8005 x121 800.466.1337 f: 205.324.7008 e: [EMAIL PROTECTED] www.NEqualsOne.com
