Sharing some more thoughts on this...
I tried doing a test run of installing seed-initial and seed data only.
I couldn't get logged in because the admin user login is in demo data -
not seed. I moved it to seed-initial - since the account should only be
created/updated during the initial install (from my perspective anyway).
I still couldn't log in because all of the components put their admin
permissions in the FULLADMIN security group, and I had left the security
group assignments in demo data. So, that security group would have to be
part of seed data too.
The goal I was aiming for was to set up a trial new installation that
had only the data needed to get the system running. It ended up being a
bigger task than I anticipated, so I dropped it.
The bottom line is, I started out thinking the boundary between seed
data and demo data is clear-cut and it would be easy to separate the
two, but it isn't.
-Adrian
David E Jones wrote:
I haven't really reviewed this for a while, and it's really frustrating
to hear this assessment.
This is definitely a critical effort, especially for those who are
maintaining production instances and need to update seed data every time
they update code. It's a probably we (hopefully!) all have.
As for the file naming conventions, to keep it simple we should probably
just say "[descriptive prefix]" instead of "[component-name]", kind of
along the lines of what Mridul mentioned.
On a related note, the main documentation for this is in the build.xml
file (in the ofbiz-home directory)... and I've been thinking that maybe
we should have something in the Best Practices Guide, or in a sub-page
of that. Maybe then more people would find it and use it.
-David
On Jun 4, 2009, at 11:11 AM, Adrian Crum wrote:
I'm getting ready to deploy the latest trunk to our production server,
and I have encountered a few problems with the way the seed data is
set up.
In order to get the latest features to work with my existing database,
I have to run ant run-install-seed. The problem is, there is a lot of
demo data in the seed files. And I really mean a LOT. After running
run-install-seed, my database contains a lot of demo data that I had
previously removed.
I would like to suggest the following best practices:
1. Keep seed-initial, seed, and demo data in separate XML files.
2. Name the files accordingly, so their purpose is clear. Example:
[component name]InitialData.xml, [component name]SeedData.xml, and
[component name]DemoData.xml.
Right now I'm working on sorting out the data for the accounting
component. The AccountingSecurityData.xml file is loaded as seed data,
but it contains both seed AND demo data: security permissions are seed
data, assigning those permissions to demo security groups is demo
data. The AccountingTypeData.xml file is loaded as seed data, but it
also contains both seed and demo data. Those are just two examples.
I can commit some of my work as an example of what changes need to be
made.
What do you think?
-Adrian
