Hello all, I have created a ticket here <https://issues.apache.org/jira/browse/OFBIZ-9902>.
I will be adding information about data model changes between OFBiz.9 to OFBiz.17.11 in the initial file. As commented on the ticket, The file will have the format: Entity Changes: Here we will have a bulleted list with entity names and the revision number 1. Added Entities 2. Removed Entities Field changes: Here we will show data in tabular form in following format: entityname | field | action | isPK | revision Any suggestions are warmly welcomed. Thanks and Regards, *Aditya Sharma* | Enterprise Software Engineer HotWax Systems <http://www.hotwaxsystems.com/> <https://www.linkedin.com/in/aditya-sharma-78291810a/> On Thu, Oct 12, 2017 at 3:02 AM, Michael Brohl <michael.br...@ecomify.de> wrote: > +1 for tracking datamodel changes together with data migration scripts > > In our customer projects, we track every change in a simple text file in > the source code repository. It contains description of the changes, > references to issues or requirement documentation and SQL scripts for > migrations. > > In OFBiz, we should at least provide SQL scripts for the embedded Derby > database, maybe there will be contributions for other databases as well. > > Something like db-changelog.derby.txt, db-changelog.mysql.txt or similar. > > Cheers, > > Michael > > Am 31.08.17 um 12:32 schrieb Taher Alkhateeb: > > Hi Ashish, >> >> With respect to Jacques' question, I kind of already answered in that >> it is not only documentation but also automation. >> >> Now with respect to which releases to incorporate, it really depends >> on what the community decides. I would personally prefer to not go any >> earlier than 13, or preferably just 16 to trunk, which means we design >> this solution for the future, not necessarily the past. The powerful >> thing in using something like liquibase is that not only do you change >> the schema (the entity engine can do that partially) but you also >> decide on how to migrate the existing data to the new schema. For >> example, you might need to split a field to two, or merge two fields, >> and so on and so forth. >> >> Anyway, this is only an idea if people are interested in it. The >> original idea of just documenting is also perfectly reasonable and >> beneficial. >> >> On Thu, Aug 31, 2017 at 8:11 AM, Ashish Vijaywargiya >> <ashish.vijaywarg...@hotwaxsystems.com> wrote: >> >>> +1, Taher. I will wait for your comment on Jacques question, we already >>> have a document but I think the automated script that can be implemented >>> here. Liquidbase and flyway seem to be promising solutions! >>> >>> One question always comes to my mind: Can we say that automated scripts >>> will support the migration from last two or at max three known releases? >>> I think we should not put the effort in building the migration script >>> that >>> could migrate ofbiz earlier version(Let's say Ofbiz 10 or 9 or 4) to the >>> latest version. Please share your thoughts on this. >>> >>> Kind Regards >>> Ashish Vijaywargiya >>> HotWax Systems - est. 1997 <http://www.hotwaxsystems.com/> >>> >>> >>> On Wed, Aug 30, 2017 at 7:54 PM, Taher Alkhateeb < >>> slidingfilame...@gmail.com >>> >>>> wrote: >>>> Good idea! Why not take it a step further, and write data migration >>>> scripts? They will serve two purposes in one: 1) document changes 2) >>>> automate upgrades. >>>> >>>> You can experiment with solutions like liquibase or flyway >>>> >>>> On Aug 30, 2017 4:23 PM, "Aditya Sharma" <aditya.sharma@hotwaxsystems.c >>>> om> >>>> wrote: >>>> >>>> Hello everyone, >>>> >>>> For one of my assignments, I need to find out entity changes that took >>>> place between an older release and the latest release. >>>> >>>> One of the solutions that came up was comparing the database using MySQL >>>> Workbench or some other utility. I found around 60+ new entity changes >>>> and >>>> a lot of minor field changes since last big book was published (OFBiz 9 >>>> I >>>> suppose). >>>> It's fascinating for me that around 8 years passed since then and data >>>> model still stands well (Kudos to Universal Data Model that we followed >>>> in >>>> OFBiz) >>>> >>>> >>>> Just a proposal, since we don't have so many frequent changes in the >>>> data >>>> model. It will be good to have a page or some other method defined to >>>> keep >>>> a track of such changes. >>>> >>>> I feel such information can be quite helpful when migrating from an >>>> older >>>> to some newer release. >>>> >>>> Please share your thoughts. >>>> >>>> Thanks and Regards, >>>> >>>> *Aditya Sharma* | Enterprise Software Engineer >>>> HotWax Systems <http://www.hotwaxsystems.com/> >>>> <https://www.linkedin.com/in/aditya-sharma-78291810a/> >>>> >>>> > >
