I have created OFBIZ-2866 that contains some description and a patch. Here is my approach in brief (as brief as I can be) =^D
Allow the entity-data-reader to indicate if that reader is going to allow inserts or updates (the default is true/true for my problem I would use true/false). These values get read by the EntityDataReaderInfo object and ultimately get bubbled down to the delegatorImpl (new storeAll method that takes the two new parameters). The biggest change here was that in the past we would gather up all URLs to process in a single generic List. The problem was at execution time I needed to know which EntityDataReaderInfo is associated with the URL. The change was to use a Map<EntityDataReaderInfo, List<URL>> -- this resulted in a few changes to the signatures and gathering techniques (but not major changes). Now it is possible to have URLs you want to process that are not associated with a EntityDataReaderInfo. This is in the (appears defunct) data source sql-load-path as well as if file/directory arguments are provided to start. In either case, I have instantiated a NO_ENTITY_DATA_READER_INFO EntityDataReaderInfo which uses the default true/true settings. When doing my testing I noticed that the metrics provided by the data load made no sense. The variables in the code were indicating that it was the "changedRows" but it was actually the number of rows that were read. I felt both were valuable, so I created a new object (EntityDataLoaderResults) which can contain all sorts of metrics -- right now just read / written. Message format was changed to show a nice set of read/written values with accumulation for the entire execution at the bottom. Found a bug in the DelegatorImpl where it was checking for "dirty" entities. What it was doing is taking the existing entity and the generic value loaded form the data source (typically xml file) and doing a .get on each of them to get the values (and comparing those values). Trouble is the .get method is a resource bundle aware method, so if one was to change a localized field it would not come up as dirty (and hence not persisted). Solution was to make "getFieldValue" public (from protected) and call this method in the delegatorImpl's dirty checking logic. Whew! I attached the patch to the JIRA ticket. In our branch I have applied this patch and changed our entityengine.xml to treat the seed-initial as true/false (insert only). This allows us to re-execute this seed-initial with each migration and only have new records added leaving any customer modified seed-initial records alone. Woo hoo! Adrian Crum wrote: > > Years ago I had suggested an attribute - something like > overwrite="true|false". It's in the old Undersun Jira. > > -Adrian > -- View this message in context: http://www.nabble.com/Handling-one-time-seed-data-tp25136333p25155909.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
