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.
