--- On Tue, 6/1/10, Matt Warnock <[email protected]> wrote: > From: Matt Warnock <[email protected]> > Subject: Production setup questions > To: [email protected] > Date: Tuesday, June 1, 2010, 4:15 PM > I have a number of newbie questions > that don't seem to be answered in > the (technical/business) Production Setup Guides. > Perhaps those of you > that have been down this path before can illuminate my > way. Should some > of these be incorporated into a FAQ of some kind, or the > Guides? Or > have I just missed them somewhere? Or do I just have > idiotic questions > that never occur to anyone else? Anyway, here > goes... > > For small companies, it is recommended that the existing > "demo" data be > modified to set up a running system. However, it is > never spelled out > (that I could see) exactly how this should be done. > As a general rule, > should you change existing demo records (using the demo > data ID) to > match your own data, or is it usually better to add new > records in the > usual way and link them up, or some combination? > > For example, the "Company" ID obviously needs to be updated > in place, as > that particular ID gets special treatment in lots of > places. But should > I follow the demo data method of having one global "admin" > (just change > the password), or should I create new separate accounts for > each actual > admin (assuming there might be more than one) and grant > them global > permissions? > > Some of the demo data has IDs that clearly identify them as > demo data. > As a rule, record IDs cannot be changed without re-creating > the record. > But many records, for example "parties", once created, > cannot be > uncreated. The argument I've seen on this list is that > there are too > many possible associated records, though a SQL "DELETE ... > CASCADE" > could solve that issue (unless it varies too much by > implementation). > So if you start out with the demo users, parties, products, > etc, how do > you eliminate the "cruft" afterward? > > Related to that, how do you merge parties that are found to > be > duplicates in your data, or that merge in real life? (OK, > probably only > party groups merge in real life.) > > On another front, I need to import thousands of parties > from another > system, and I don't want to retype them all. I can't > (easily) just dump > to postgresql because the OFBiz table structure is very > complex, with > names, addresses, phone numbers, customer IDs, and other > data in > separate tables (a good thing, but it vastly complicates > data import). > Can I call a service to import this data from a CSV or > other relatively > common format with a custom-designed data map of some > kind?
If the other system uses a database that you can access with a JDBC driver, then you won't need an intermediate file format. Just make entity definitions for the other system and access the data using the delegator. You can then write a service to sync data. > Same question, part 2: running in parallel with my old > system, I may > need to import data again. Can I import only the NEW > data (can ofbiz > check for existence during import) so that data isn't > duplicated by > every re-import? > > How do you keep a production database (like postgresql) > up-to-date with > the OFBiz code changes? Does it ALL happen > automatically every time you > "./ant run", or is there something more needed? > Do/should you EVER have > to do "run-install" or "run-install-seed" again? What > if seed data > changes, like for fixes to geographic data errors? > Does "demo" data > EVER change in any way that would later need to be > incorporated into a > production database? > > If so, just how much does "run-install" (accidentally or on > purpose) > replace on an existing database? Since "run-install" > is the recommended > method for small companies (rather that building from > scratch via seed), > it seems like the behavior of "run-install" on an EXISTING > production > database (or a clear recommendation/warning to NEVER do > such a > crazy/stupid thing) should be well documented. For > example, I know that > running "run-install" on a production database will reset > your passwords > to the defaults (which is probably not a good thing on a > production > database, and surprises me because I would expect a failed > insert rather > than a successful update), but don't know what else might > get broken. If > "run-install" should never happen twice, should it check > for existing > data (perhaps in "Company") before blindly overwriting > production data? > > In a similar vein, I know that "clean-data" only works with > the Derby > database, by removing the Derby data files at the OS level, > not through > the entity engine. Therefore, it won't clean a > production database > (probably a good thing). Is there (or depending on > answers to the > above, should there be) a way to clean demo data (ONLY demo > data) from a > production database? > > Also, can I have multiple branches of OFBiz running against > the same > production database? For example, maybe my admins or > developers (who > have some tolerance for freshly broken code) use trunk, but > maybe I want > my data entry people, and the customer-facing web store, to > run a more > stable version, like 9.04 or 10.04. Is this scenario > recommended or > advisable? It seems like this may be a way to run > trunk (for at least > some people), but still have another way to make a needed > change (short > of the SQL command line) if the trunk code is currently > broken. However, > the Setup Guides make it sound like a choice between > mutually exclusive > alternatives. > > Finally, I read that /hot-deploy is the place for apps that > are local in > nature, and can even over-ride existing ofbiz stock > code. Is there a > way to put local mods of the ofbiz framework configs (like > the > production cache flags and entity engine configuration) in > /hot-deploy > so any changes can 1) be easily diff'ed against stock code, > and 2) > managed/excluded as local code that way, rather than using > the three-way > SVN merge that BJ described for me earlier? Put your custom code in hot-deploy, then create patches for changing settings. You should also keep your custom code in a local repository. So, the workflow would be: 1. Check out OFBiz from Apache repository. 2. Check out custom code from local repository, place it in hot-deploy. 3. Apply patch for configuration settings. The patch could be kept with the custom code - so that it can be kept under revision control too. > > TIA. Sorry for the several (hopefully related) > questions at once. > > -- > Matt Warnock <[email protected]> > RidgeCrest Herbals, Inc. > > > >
