Years ago I had suggested an attribute - something like
overwrite="true|false". It's in the old Undersun Jira.
-Adrian
Bob Morley wrote:
Hey Joe -- are you referring to entities that get a sequence id from the
SequenceValueItem table? While not being an expert with the data loaders, I
would have thought that they do not play a role in the data loading. I
would have thought that we load the entity from the xml definition, get the
primary keys from the entity definition, then do a look-up to see if the
entity exists. If it does not -> INSERT and if it does -> UPDATE. (This is
just a guess without digging into the code yet).
What I am proposing is either an attribute for the loader that indicates we
only want to insert entities for that loader or a "keyword" attribute on the
entity that indicates we only want to insert that entity.
Am I wrong in my thinking on the auto-sequence entities?
Joe Eckard wrote:
Would it be able to detect auto-sequenced entities? Just thinking out
loud...
On Aug 25, 2009, at 3:34 PM, David E Jones wrote:
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.
