Loading ...
Sorry, an error occurred while loading the content.

Re: how to sequence database refactorings?

Expand Messages
  • Steve
    Hi Pramod, I m using a similar approach, but haven t quite yet figured out how to deal with source code branches (for fixes, spikes, etc.). How are you dealing
    Message 1 of 15 , Jul 2, 2004
    • 0 Attachment
      Hi Pramod,

      I'm using a similar approach, but haven't quite yet figured out how
      to deal with source code branches (for fixes, spikes, etc.).

      How are you dealing with it? I understand the concept of database
      lineages (from Martin's article)... do you use lineages as units of
      configuration management? How do you keep track of which lineages go
      with which (application) source code files? Is that handled by your
      stored procedure as well?

      Regards

      Steve Tendon

      --- In agileDatabases@yahoogroups.com, Pramod <psadalage@y...> wrote:
      > here are the details, I stripped out the previous
      > msg's for clarity sake.. hopefully the formatting
      > makes sense :)
      >

      <snip>
    • Pramod
      Steve, every code branch has its own set of change files (scripts) because when we branch code our DB folder (which includes all the schema creation scripts,
      Message 2 of 15 , Jul 2, 2004
      • 0 Attachment
        Steve,

        every code branch has its own set of change files
        (scripts) because when we branch code our DB folder
        (which includes all the schema creation scripts, data
        population scripts and all the change scripts) is also
        included in the branch, that way the change files go
        along with the code branch.

        we have maintained many branches this way.

        Also the stored procedure does handle different codes
        branches (all you have to do is add code_branch
        checking to the example I sent to some folks, actually
        I stripped it out before sending the example out :( ).
        No we do not use lineage as an unit of configuration
        management since a lineage is made up of
        schema + application setup data + test data.
        There could be n number of lineages within the same
        code branch or even for a given build.

        We always keep track of lineages by their name
        say I10_QA for Iteration 10 QA database or I11_PERF
        for Iteration 11 Performance database or things
        similar to that

        Pramod

        --- Steve <spam.target@...> wrote:
        > Hi Pramod,
        >
        > I'm using a similar approach, but haven't quite yet
        > figured out how
        > to deal with source code branches (for fixes,
        > spikes, etc.).
        >
        > How are you dealing with it? I understand the
        > concept of database
        > lineages (from Martin's article)... do you use
        > lineages as units of
        > configuration management? How do you keep track of
        > which lineages go
        > with which (application) source code files? Is that
        > handled by your
        > stored procedure as well?
        >
        > Regards
        >
        > Steve Tendon
        >
        > --- In agileDatabases@yahoogroups.com, Pramod
        > <psadalage@y...> wrote:
        > > here are the details, I stripped out the previous
        > > msg's for clarity sake.. hopefully the formatting
        > > makes sense :)
        > >
        >
        > <snip>
        >
        >


        =====




        __________________________________
        Do you Yahoo!?
        Take Yahoo! Mail with you! Get it on your mobile phone.
        http://mobile.yahoo.com/maildemo
      • Steve
        According to these scheme, how do you handle merges of different branches - especially with production databases. For instance, if you have a bugfix branch
        Message 3 of 15 , Jul 5, 2004
        • 0 Attachment
          According to these scheme, how do you handle merges of different
          branches - especially with production databases. For instance, if you
          have a bugfix branch which you want to merge into the mainline, you
          have to cater for the situation where some customers have a database
          that comes from the branch (they have deployed the bugfix), while
          others have a database that comes from the mainline (they have not
          deployed the bugfix). At the mergepoint you would have to run two
          different sets of scripts to handle the merge.

          Another situation is where some customers are on a customization
          branch, and then that customization goes into the mainline and you
          get a mergepoint. Again you would have two distinct upgrade paths for
          the production databases: one for the customers with the
          customization and one for those without it.

          How do you handle the above scenarios?

          Cheers

          -ST


          --- In agileDatabases@yahoogroups.com, Pramod <psadalage@y...> wrote:
          > Steve,
          >
          > every code branch has its own set of change files
          > (scripts) because when we branch code our DB folder
          > (which includes all the schema creation scripts, data
          > population scripts and all the change scripts) is also
          > included in the branch, that way the change files go
          > along with the code branch.
          >
          <snip>
        • Pramod
          Sorry it took so long to reply, go side tracked with other stuff. Comments below. Thanks Pramod ... We handle this using the revision or release identifier on
          Message 4 of 15 , Jul 14, 2004
          • 0 Attachment
            Sorry it took so long to reply, go side tracked with
            other stuff. Comments below.

            Thanks
            Pramod
            --- Steve <spam.target@...> wrote:
            > According to these scheme, how do you handle merges
            > of different
            > branches - especially with production databases. For
            > instance, if you
            > have a bugfix branch which you want to merge into
            > the mainline, you
            > have to cater for the situation where some customers
            > have a database
            > that comes from the branch (they have deployed the
            > bugfix), while
            > others have a database that comes from the mainline
            > (they have not
            > deployed the bugfix). At the mergepoint you would
            > have to run two
            > different sets of scripts to handle the merge.


            We handle this using the revision or release
            identifier on the VersionLog table.
            Every change that is made to the database has to be
            logged and tracked in this
            versionlog table with the release being either the
            BugFix version or the Head Version, there on it does
            not matter what branch of the code base you
            made the change in, since before applying a change you
            can check if the particular change was made to the
            database (production in your case ) or not if
            it was not made then you go ahead and make the change.
            The sticking point is how to merge the base scripts
            (the script that creates all the tables/views/indexes
            etc), I guess it would have to be handled like any
            code merge

            >
            > Another situation is where some customers are on a
            > customization
            > branch, and then that customization goes into the
            > mainline and you
            > get a mergepoint. Again you would have two distinct
            > upgrade paths for
            > the production databases: one for the customers with
            > the
            > customization and one for those without it.

            Again I think this is the same situation as above, as
            long as you are tracking,
            logging and applying database changes for each branch
            then you can easily
            determine if the given change was applied to the
            customized Version or the Main
            branch or not

            >
            > How do you handle the above scenarios?


            =====




            __________________________________
            Do you Yahoo!?
            Yahoo! Mail - You care about security. So do we.
            http://promotions.yahoo.com/new_mail
          Your message has been successfully submitted and would be delivered to recipients shortly.