ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Warnock <mwarn...@ridgecrestherbals.com>
Subject Production setup questions
Date Tue, 01 Jun 2010 23:15:04 GMT
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?

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?

TIA.  Sorry for the several (hopefully related) questions at once.

-- 
Matt Warnock <mwarnock@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.




Mime
View raw message