There is a manual way to do this, ie make sure the data in the
database and the file are how you want them to be.
On the entity XML import page (https://demo.ofbiz.org/webtools/control/EntityImportReaders
) there is a checkbox called "Check Data Only (nothing changed in
database)". If that is checked you'll see the differences between the
data file and the database and you can resolve them manually, or not,
as desired.
This may or may not be helpful. It could be expanded into a sort of
merge tool, but it certainly isn't that right now.
The alternative you mentioned is interesting and might work out fine,
ie have an option to only insert and not change existing records.
-David
On Aug 25, 2009, at 10:22 AM, Bob Morley wrote:
Yep there are some solutions like that; however envision 1000
customers. We
are building out a SaaS based solution built on Ofbiz, and have the
infrastructure in place to handle re-provisioning the latest
software and
upgrading the multitude of databases (1 customer per database).
I believe what we do right now is that we schedule jobs via the
Ofbiz job
scheduler to perform the Ofbiz "seed" (one job per customer). Once
this job
is complete, it triggers re-provisioning of the customer to one of the
virtual servers running the latest build. So what happens is that the
customers naturally migrate from their rev 1 server to a new rev 2
server
along with their automated database upgrade. Eventually, all
customers have
moved off of rev 1 and that virtual sever is decommissioned.
Things work very well with the Ofbiz loaders, we just have this one
little
gap. :) If we feel this is something that should just be custom to
us that
is fine; but we felt that there may be value in an enhancement for the
community in general.
Joe Eckard wrote:
Let me back up a bit - ignore the custom reader(s) comment for now.
It seems like there are several low-tech ways around the problem...
why not update your "seed-initial" file with the new data for future
installs, and for any existing installations, manually import just
that new data using the webtools entity import screen. (simple copy /
paste or load from a file you push out to them)
-Joe
On Aug 25, 2009, at 11:45 AM, Bob Morley wrote:
Hey Joe,
Right we do a similar thing (the actual data is in separate files)
but it is
the loader configuration from the ant target that is the issue here.
It is really the insert/update behavior of all of the readers. If I
have
data that I want to be only seeded initially (based on that ant
target) but
I have added to it and require this to be applied to current
installations I
am stuck. If I put it in my "seed-initial" file then it will not be
executed against an existing installation and if I put it in my
"seed" file
then it will be executed every time.
Does this make sense or perhaps I am not explaining the issue very
well?
Joe Eckard wrote:
Why not create an additional custom reader (or readers)? See: the
"ext" reader for an example. Also, the ext reader is where I put
all
of my customer-specific data, I don't touch seed-initial or seed.
There's nothing special about seed-initial or seed except that they
are explicitly referenced to in the stock ant targets.
-Joe
On Aug 25, 2009, at 11:13 AM, Bob Morley wrote:
Background:
There are a number of data loaders in Ofbiz including "seed" and
"seed-initial". We use "seed-initial" as part of the database
creation
which is applied to the data once one time only. We use "seed" to
ensure
that standard entities are inserted/updated each time Ofbiz starts
(or for
us as part of each customer migration).
The implication of this is that "seed-initial" will be standard
entities
that are loaded, but we do not want to seed them each time (often
because
the user in Ofbiz may modify these entities).
Requirement:
We have situations where we have entities that need to be seeded
as
"seed-initial" but they are added after the fact and need to be
applied to
customer deployments. Here is a theoretical example, I put a
ProductStore
in my "seed-initial" and a customer provisions a deployment and
gets
seeded
with that store. Later on we decide that we should seed two
stores
for all
our customers so we create a second store in "seed-initial". The
trouble is
that we can not execute seed-initial again, and it does not make
sense to
put this second store in "seed" (because we do not want it to be
updated on
a future seed).
Potential Solution:
We considered the idea of making "seed-initial" strictly INSERT
(not
UPSERT
as it is now) but we are leaning towards adding a "keyword" to the
seed
entities that allows that entity to "insert-only". The benefit of
the
second approach, is that we can can keep things like the product
store
"contextually close" to other seeded data preventing the split
between
"seed" and "seed-initial".
Looking for some thoughts on this. Perhaps there is another way
to
get
"insert-only" type entities to be seeded that I have not found or
perhaps
there exists some configuration for each data loader.
--
View this message in context:
http://www.nabble.com/Handling-one-time-seed-data-tp25136333p25136333.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Handling-one-time-seed-data-tp25136333p25136933.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/Handling-one-time-seed-data-tp25136333p25137625.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
