You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Nicolas Malin <ni...@nereide.fr> on 2017/09/01 11:23:58 UTC
Re: Tracking Data Model changes
I'm in favor to tracking the different migration but at this time I
didn't see the advantage to use flyway or other instead of manage easily
by ofbiz throw groovy script.
I'm available to help for design or create a POC do realize it because
many time in the past (and currently ow) I want to refactoring some
code/db schema with data migration but we haven't clean process to do that.
Nicolas
Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>> 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.
> +1
>
> Jacques
>
>
Re: Tracking Data Model changes
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
That would be a much effective solution.
As far as https://cwiki.apache.org/confluence/display/OFBIZ/
Revisions+Requiring+Data+Migration+-+upgrade+ofbiz page is concerned I find
it quite absurd that we provide information based upon only revisions while
users deal with releases.
Though it would be better to link it to data migration page so that user
gets all information through a single path.
Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems <http://www.hotwaxsystems.com/>
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Sat, Sep 23, 2017 at 2:22 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi Aditya,
>
> One way we could use and is already used for the Gradle and Birt Flexible
> documentation in wiki is to create README.md files, uses Pandoc to generate
> a HTML file from it in tools\wiki-files and import this file in wiki using
> the HTML import macro.
>
> Doing so we follow both way you suggested. So users have it in 2 places
> while it's only maintained in one place where it's versioned (though
> Confluence also versions pages)
>
> Maybe an overkill in this case though. Since we have already
> https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+
> Requiring+Data+Migration+-+upgrade+ofbiz to start from
>
> My 2cts
>
> Jacques
>
>
> Le 23/09/2017 à 10:41, Aditya Sharma a écrit :
>
>> I see two ways to do that
>>
>> 1. A page maintained on Confluence where all the data model changes are
>> updated. Here, we can have a page maintained for the upcoming release when
>> the release is out we make it sub child titled with the release name.
>> 2. A file is maintained in ofbiz-framework code base itself that goes with
>> the package with information about data model changes. Whenever someone
>> downloads the package this file will help track data model changes that
>> come with the package.
>>
>> We can make it part of contributor's practice to update it whenever such
>> changes are done.
>>
>> Which way should we go?
>>
>> Thanks and Regards,
>>
>> *Aditya Sharma* | Enterprise Software Engineer
>> HotWax Systems <http://www.hotwaxsystems.com/>
>> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>>
>> On Sun, Sep 10, 2017 at 4:46 PM, Michael Brohl <mi...@ecomify.de>
>> wrote:
>>
>> +1 for the documentation of database changes.
>>>
>>> We alreadyy do this for customer projects, along with (database specific)
>>> data migration scripts.
>>>
>>> I'm not sure if we can afford to provide sophisticated additional tool
>>> support which is maintained continiously?
>>>
>>>
>>> As a conclusion, I think we should setup a convention that any database
>>> model change has to provide a proper change log and migration script for
>>> the embedded database (if applicable).
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 01.09.17 um 15:24 schrieb Taher Alkhateeb:
>>>
>>> Groovy scripts are also great and can do the job. To comment on the
>>>
>>>> "advantage" of something like flyway or liquibase I can try to list
>>>> some:
>>>> - The scripts might get too big or complex to accommodate different
>>>> databases and platforms.
>>>> - Out of the box, these solutions are database independent
>>>> - Ability to redo / undo on schema changes
>>>> - Supporting declarative style for schema definitions based on
>>>> multiple formats (YAML, XML, JSON, etc ..)
>>>> - The DSL is easier to use (declarative and short)
>>>>
>>>> So in short, both solutions are viable, and existing solutions might
>>>> be a bit easier to implement especially if you consider additional
>>>> features in those solutions.
>>>>
>>>> On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <nicolas.malin@nereide.fr
>>>> >
>>>> wrote:
>>>>
>>>> I'm in favor to tracking the different migration but at this time I
>>>>> didn't
>>>>> see the advantage to use flyway or other instead of manage easily by
>>>>> ofbiz
>>>>> throw groovy script.
>>>>>
>>>>> I'm available to help for design or create a POC do realize it because
>>>>> many
>>>>> time in the past (and currently ow) I want to refactoring some code/db
>>>>> schema with data migration but we haven't clean process to do that.
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>> Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
>>>>>
>>>>> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>
Re: Tracking Data Model changes
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Aditya,
One way we could use and is already used for the Gradle and Birt Flexible documentation in wiki is to create README.md files, uses Pandoc to generate
a HTML file from it in tools\wiki-files and import this file in wiki using the HTML import macro.
Doing so we follow both way you suggested. So users have it in 2 places while it's only maintained in one place where it's versioned (though
Confluence also versions pages)
Maybe an overkill in this case though. Since we have already
https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz to start from
My 2cts
Jacques
Le 23/09/2017 à 10:41, Aditya Sharma a écrit :
> I see two ways to do that
>
> 1. A page maintained on Confluence where all the data model changes are
> updated. Here, we can have a page maintained for the upcoming release when
> the release is out we make it sub child titled with the release name.
> 2. A file is maintained in ofbiz-framework code base itself that goes with
> the package with information about data model changes. Whenever someone
> downloads the package this file will help track data model changes that
> come with the package.
>
> We can make it part of contributor's practice to update it whenever such
> changes are done.
>
> Which way should we go?
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems <http://www.hotwaxsystems.com/>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> On Sun, Sep 10, 2017 at 4:46 PM, Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> +1 for the documentation of database changes.
>>
>> We alreadyy do this for customer projects, along with (database specific)
>> data migration scripts.
>>
>> I'm not sure if we can afford to provide sophisticated additional tool
>> support which is maintained continiously?
>>
>>
>> As a conclusion, I think we should setup a convention that any database
>> model change has to provide a proper change log and migration script for
>> the embedded database (if applicable).
>>
>> Thanks,
>>
>> Michael
>>
>>
>> Am 01.09.17 um 15:24 schrieb Taher Alkhateeb:
>>
>> Groovy scripts are also great and can do the job. To comment on the
>>> "advantage" of something like flyway or liquibase I can try to list
>>> some:
>>> - The scripts might get too big or complex to accommodate different
>>> databases and platforms.
>>> - Out of the box, these solutions are database independent
>>> - Ability to redo / undo on schema changes
>>> - Supporting declarative style for schema definitions based on
>>> multiple formats (YAML, XML, JSON, etc ..)
>>> - The DSL is easier to use (declarative and short)
>>>
>>> So in short, both solutions are viable, and existing solutions might
>>> be a bit easier to implement especially if you consider additional
>>> features in those solutions.
>>>
>>> On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <ni...@nereide.fr>
>>> wrote:
>>>
>>>> I'm in favor to tracking the different migration but at this time I
>>>> didn't
>>>> see the advantage to use flyway or other instead of manage easily by
>>>> ofbiz
>>>> throw groovy script.
>>>>
>>>> I'm available to help for design or create a POC do realize it because
>>>> many
>>>> time in the past (and currently ow) I want to refactoring some code/db
>>>> schema with data migration but we haven't clean process to do that.
>>>>
>>>> Nicolas
>>>>
>>>>
>>>> Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
>>>>
>>>>> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>>>>>
>>>>>> 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.
>>>>>>
>>>>> +1
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>
Re: Tracking Data Model changes
Posted by Aditya Sharma <ad...@hotwaxsystems.com>.
I see two ways to do that
1. A page maintained on Confluence where all the data model changes are
updated. Here, we can have a page maintained for the upcoming release when
the release is out we make it sub child titled with the release name.
2. A file is maintained in ofbiz-framework code base itself that goes with
the package with information about data model changes. Whenever someone
downloads the package this file will help track data model changes that
come with the package.
We can make it part of contributor's practice to update it whenever such
changes are done.
Which way should we go?
Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems <http://www.hotwaxsystems.com/>
<https://www.linkedin.com/in/aditya-sharma-78291810a/>
On Sun, Sep 10, 2017 at 4:46 PM, Michael Brohl <mi...@ecomify.de>
wrote:
> +1 for the documentation of database changes.
>
> We alreadyy do this for customer projects, along with (database specific)
> data migration scripts.
>
> I'm not sure if we can afford to provide sophisticated additional tool
> support which is maintained continiously?
>
>
> As a conclusion, I think we should setup a convention that any database
> model change has to provide a proper change log and migration script for
> the embedded database (if applicable).
>
> Thanks,
>
> Michael
>
>
> Am 01.09.17 um 15:24 schrieb Taher Alkhateeb:
>
> Groovy scripts are also great and can do the job. To comment on the
>> "advantage" of something like flyway or liquibase I can try to list
>> some:
>> - The scripts might get too big or complex to accommodate different
>> databases and platforms.
>> - Out of the box, these solutions are database independent
>> - Ability to redo / undo on schema changes
>> - Supporting declarative style for schema definitions based on
>> multiple formats (YAML, XML, JSON, etc ..)
>> - The DSL is easier to use (declarative and short)
>>
>> So in short, both solutions are viable, and existing solutions might
>> be a bit easier to implement especially if you consider additional
>> features in those solutions.
>>
>> On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <ni...@nereide.fr>
>> wrote:
>>
>>> I'm in favor to tracking the different migration but at this time I
>>> didn't
>>> see the advantage to use flyway or other instead of manage easily by
>>> ofbiz
>>> throw groovy script.
>>>
>>> I'm available to help for design or create a POC do realize it because
>>> many
>>> time in the past (and currently ow) I want to refactoring some code/db
>>> schema with data migration but we haven't clean process to do that.
>>>
>>> Nicolas
>>>
>>>
>>> Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
>>>
>>>> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>>>>
>>>>> 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.
>>>>>
>>>> +1
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>
>
Re: Tracking Data Model changes
Posted by Michael Brohl <mi...@ecomify.de>.
+1 for the documentation of database changes.
We alreadyy do this for customer projects, along with (database
specific) data migration scripts.
I'm not sure if we can afford to provide sophisticated additional tool
support which is maintained continiously?
As a conclusion, I think we should setup a convention that any database
model change has to provide a proper change log and migration script for
the embedded database (if applicable).
Thanks,
Michael
Am 01.09.17 um 15:24 schrieb Taher Alkhateeb:
> Groovy scripts are also great and can do the job. To comment on the
> "advantage" of something like flyway or liquibase I can try to list
> some:
> - The scripts might get too big or complex to accommodate different
> databases and platforms.
> - Out of the box, these solutions are database independent
> - Ability to redo / undo on schema changes
> - Supporting declarative style for schema definitions based on
> multiple formats (YAML, XML, JSON, etc ..)
> - The DSL is easier to use (declarative and short)
>
> So in short, both solutions are viable, and existing solutions might
> be a bit easier to implement especially if you consider additional
> features in those solutions.
>
> On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <ni...@nereide.fr> wrote:
>> I'm in favor to tracking the different migration but at this time I didn't
>> see the advantage to use flyway or other instead of manage easily by ofbiz
>> throw groovy script.
>>
>> I'm available to help for design or create a POC do realize it because many
>> time in the past (and currently ow) I want to refactoring some code/db
>> schema with data migration but we haven't clean process to do that.
>>
>> Nicolas
>>
>>
>> Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
>>> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>>>> 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.
>>> +1
>>>
>>> Jacques
>>>
>>>
Re: Tracking Data Model changes
Posted by Taher Alkhateeb <sl...@gmail.com>.
Groovy scripts are also great and can do the job. To comment on the
"advantage" of something like flyway or liquibase I can try to list
some:
- The scripts might get too big or complex to accommodate different
databases and platforms.
- Out of the box, these solutions are database independent
- Ability to redo / undo on schema changes
- Supporting declarative style for schema definitions based on
multiple formats (YAML, XML, JSON, etc ..)
- The DSL is easier to use (declarative and short)
So in short, both solutions are viable, and existing solutions might
be a bit easier to implement especially if you consider additional
features in those solutions.
On Fri, Sep 1, 2017 at 2:23 PM, Nicolas Malin <ni...@nereide.fr> wrote:
> I'm in favor to tracking the different migration but at this time I didn't
> see the advantage to use flyway or other instead of manage easily by ofbiz
> throw groovy script.
>
> I'm available to help for design or create a POC do realize it because many
> time in the past (and currently ow) I want to refactoring some code/db
> schema with data migration but we haven't clean process to do that.
>
> Nicolas
>
>
> Le 31/08/2017 à 12:37, Jacques Le Roux a écrit :
>>
>> Le 31/08/2017 à 12:32, Taher Alkhateeb a écrit :
>>>
>>> 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.
>>
>> +1
>>
>> Jacques
>>
>>
>