Hi all: Sorry for the length of this post, but I'm trying to get a handle on best practices for code updates, and want to make sure I understand the process. I envision that the upgrade process for a production database goes something like this:
1) Backup everything (code and DB), in case you have to roll back. 2) Do "svn info" and note OLD revision number (is it in DB at all?). 3) Do "svn up" and note NEW revision number. 4) Check the wiki page BJ cites below to see what DB changes are needed. 5) Build the new code, integrating local modifications. 7) Test like crazy, especially the DB migration services/changes. 8) Automate & test migration process with a copy of the production DB. 9) Roll out new DB and server, ready with fast "rollback" if needed. 10) Make sure that the business stays up and running. Whether this process is done weekly, monthly, or "as feasible" with trunk, or only every year or two between OOTB stable releases, the upgrade path is about the same, is it not? The only real difference is the number of database changes that might be needed, and the time frame for advance testing on the selected new code revision. Could there be data migration issues from one revision to an other within release 9.04, for example? I'm assuming that would be unlikely, at least. It seems like running one consistent production DB, under two different versions of OFBiz, is likely to be problematic. So the actual conversion of the production DB probably needs to be done overnight, if possible. As the newly-modified production database is used in practice, and diverges from the old-version backup, "rolling back" soon becomes increasingly painful (days of lost work), eventually becoming a non-option. Am I envisioning this correctly? David warned last week or so that the data migration page BJ cites below is manually updated, therefore not guaranteed to be 100% correct. It also seems to only contain changes to table structure, not to seed data. I assume that new code may depend not only on new table structure, but also on data types and distinctions defined in new, additional seed data. Thinking about that, I conclude that it would be really important to know, in a fully automated way, what differences exist in the entity definitions, or seed data content, between arbitrary revisions X and Y. Does such a tool exist? Or does the entity-check code run on startup somehow fully answer that need? If not, it occurs to me that if I do a pg_dump (or the equivalent in Derby) immediately after running "./ant run-install-seed" for two arbitrary versions of OFBiz, I should be able to "diff" the two resulting files and see *ALL* the changes to both table structure, and seed data. A little more munging of those results could yield a more meaningful result, like "In table XYZ, change field "ABC" from "char(25)" to "char(30)", or "add (or subtract) a row of seed data as follows:" Are there problems you see with such an approach (other than it is totally DB-specific, of course). Am I worrying too much? I'm not betting the farm on OFBiz today, but if all goes according to plan, I soon will be. -- Matt Warnock <mwarn...@ridgecrestherbals.com> RidgeCrest Herbals, Inc. On Wed, 2010-09-15 at 17:39 -0700, BJ Freeman wrote: > though I have seen the first one did not dig in since it did not effect > what I was doing. > > second one says that there is no entity in the current version that > matches your DB table. > usually you will find the entity named old and a new entity will be used. > if your running productions servers you need to check if it effects your > current system. if so then you need to do a migration. > also check > https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration > > Matt Warnock sent the following on 9/15/2010 3:56 PM: > > Running trunk (996145 under Debian with postgresql 8.3. > > > > When I run, I get two kinds of warnings that I don't understand: > > > > First off, there are 8 or so warnings like this: > > 2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ] > > Conversion for complex-alias needs to be implemented for cache and > > in-memory eval stuff to work correctly, will not work for alias: > > statusDelay of view-entity ExampleStatusDetail > > > > Second, when I start OFBiz on an EXISTING postgresql database, I get the > > following kind of warning for EACH table in the database: > > > > 2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ] > > Table named [public.CURRENCY_DIMENSION] exists in the database but has > > no corresponding entity > > > > I suspect the latter is some kind of mismatch between the "public" > > schema and the tablename without the schema portion. > > > > Should I be concerned about either of these kinds of warnings? I > > googled them both, found they had been asked before, but could not find > > any answers. Does anyone know? > > > >
