>We have a couple of classes that wrap OJB, so we have, uninspiringly named, >DBManager and DBManagerFactory (actually a factory and factory factory in
Just to clarify - DBManagerFactory internally creates/manages factories (can configure more than one keyed on name) that create DBManagers, which equates to a PersistenceBroker or connection. Not the best names, perhaps. Anyway, here's the code that would sync a database up to the current schema definition. The connection returned by the OJB implementation in factory.getConnection() returns a proxy wrapper that calls broker.close() on the connection close so it doesn't circument OJB's normal lifecycle. It creates a string of ddl and executes it all, which is basically how the existing sql code worked. InputStream is = //find xml DatabaseReader reader = new DatabaseReader(); Database db = (Database) reader.parse( is ); Connection existing = factory.getConnection(); StringWriter swriter = new StringWriter(); SqlBuilder builder = SqlBuilderFactory.newSqlBuilder( def.getDatabaseType() ); builder.setWriter(swriter); builder.alterDatabase( db, existing, false, true ); //no drops, modify colums (type/size) DDLExecutor exec = new DDLExecutor( new ConnectionDataSource(existing) ); String sql = swriter.toString(); exec.evaluateBatch( sql ); John Marshall >===== Original Message From John <[EMAIL PROTECTED]> ===== >http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] e.org&msgId=751212 > >I submitted the changes once to the list and once to one of the developers. I >think it was Jason Van Zyl. He seemed interested. I think this patch was >based on the code in CVS after the jelly ddl creation was added, but I'm not >sure. I can make the whole src package available, too. > >I also posted the xsl to this list at one point because other people were >asking about it and it's mentioned in the OJB docs that such a thing should be >possible, but I don't know if anyone ever did anything with it. I can repost >that if you want. > >We have a couple of classes that wrap OJB, so we have, uninspiringly named, >DBManager and DBManagerFactory (actually a factory and factory factory in >one). Theoretically we could swap out OJB, but mostly these classes just keep >the configuration and access the same and allow us to add some utility stuff >based on our normal conventions. Anyway, when the factory factory first >initializes all the stuff for one factory (database), it checks the schema. >Then the factory is free to create connections, which are PersistenceBrokers >for us. Nothing magic, just nice to use. > >John Marshall > > > >>===== Original Message From Gus Heck <[EMAIL PROTECTED]> ===== >>John, >> Thanks for the reply! Comments inline. >> >>-Gus >> >>John wrote: >> >>>Gus, I have modified the jakarta-commons-sandbox/sql project (was supposed >to >>>move to db.apache.org, but hasn't). Previously it could only create ddl for >>>any database from a torque-style xml, but I added support to do a diff from >an >>>existing database and generate ddl to add and remove columns, tables, and >>>indices. With a flag you can have it generate the entire ddl or just the >ddl >>>for new stuff, the drops are optional, too. >>> >>Cool. This sounds excellent. Exactly what I need. I feel better about >>not having found it yet too :). >> >>> Unfortunately, the project owners >>>never accepted (had time to?) put my patches in, but I can make them >>>available. >>> >>Yeah, that would be interesting, please do. Even better if it could >>actually get added to the project. If you point me to where you >>submitted it or some such I would be willing to add a vote (if it is in >>bugzilla) and/or a feature request mail to their list. >> >>> This project was supposed to replace the ddl generation part of >>>Torque and let it focus on just the O-R mapping, but I don't think that is >>>going to happen soon. I haven't followed Torque for a while, but neither it >>>nor anything else I looked at could bring a db up-to-date, just create one >>>from scratch, so that's why I did the work. >>> >>> >>Well there is no reason it can't provide the capability in the mean time >>until Torque implements something, or the torque crew switches over to >>using commons.... >> >>>I have an xsl that transforms my ojb repository.xml to the database xml, but >>>any other method that exists for generating that should work. You could use >>>the sandbox/sql ant tasks within maven/ant to create/modify your database. >>> >>This sounds like the easiest first route.... >> >>> Or >>>you could do like me and check the schema when initializing OJB so the >>>database is always up to date. >>> >>> >>Could you elaborate on this? >> >>>John Marshall >>>Connectria >>> >>> >>> >>>===== Original Message From Gus Heck <[EMAIL PROTECTED]> ===== >>>Well things seem to be moving along, and I finally have tamed enough of >>>struts, xdoclet and OJB configuration and understood enough JDO to >>>actually get to the point where my web app tries to write to the >>>database. (YEA!) I was not supprised however to get this exception: >>> >>>java.sql.SQLException: General error, message from server: "Table >>> >>> >>>'fdbtest2.LocationBase' doesn't exist" >>> >>> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1825) >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1020) >>> >>>I kinda figured that I handn't yet done anything to propogate the tables >>>into the database. XDoclet is nicely generating my repository_user.xml >>>file, and I am wondering if there is a way to push the tables into the >>>database (based on the repository.xml file) at runtime. Ideally, I would >>>like the following in the end: >>> >>>From my ant file; >>>reload (with tomcat ant task) mode.testing = true >>> - drop the test database >>> - recreate the test database >>> - create the tables >>> - run the app. >>> >>>reload (with tomcat ant task) mode.testing = false >>> - DO NOT drop the test database >>> - add any tables that are missing (new classes to persist) to the >>>database >>> - run the app. >>> >>>The first scenario basically mirrors the unit test test database setup I >>>think, but the second seems to require the ability to do a create if >>>needed, which I suspect won't be easy from ant (unless I write a custom >>>task, which is somthing I might consider doing). I am hopping that there >>>is a nice easy way to push tables into the database (using OJB from >>>java), if they don't exist. (but I havn't found it yet in the docs) >>>Since It didn't jump out at me I was wondering if this is something >>>already well know to people on this list. If I can do it via >>>configuration settings for the OJB back end and not venture beyond the >>>JDO API in my code that would be nice too, but I expect that that is >>>probably asking too much. >>> >>>Seeking suggestions.... >>> >>>Gus >>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
