Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. This code will self-destruct in...

This code will self-destruct in...

Scheduled Pinned Locked Moved The Lounge
databasequestion
43 Posts 27 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • W W Balboos GHB

    1 - No difference. If the new column exists then all the operations operate on the new set of fields; if it doesn't exist, use the old set. 2 - I don't consider agile.   You example - which strongly implies a rush to just have something to show - anything - underscores my distaste.   I'm of the school of thought: try to do it right the first time.

    Ravings en masse^

    "The difference between genius and stupidity is that genius has its limits." - Albert Einstein

    "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

    J Offline
    J Offline
    jschell
    wrote on last edited by
    #41

    W∴ Balboos wrote:

    No difference. If the new column exists then all the operations operate on the new set of fields; if it doesn't exist, use the old set.

    Which means, after a while, that you are going to have a lot of conditional code.

    W∴ Balboos wrote:

    I'm of the school of thought: try to do it right the first time.

    I have been doing databases for 30 years. Never worked anywhere where the database was static. Been doing startups for 20 years. And persistence models are definitely dynamic in those.

    W 1 Reply Last reply
    0
    • J jschell

      W∴ Balboos wrote:

      No difference. If the new column exists then all the operations operate on the new set of fields; if it doesn't exist, use the old set.

      Which means, after a while, that you are going to have a lot of conditional code.

      W∴ Balboos wrote:

      I'm of the school of thought: try to do it right the first time.

      I have been doing databases for 30 years. Never worked anywhere where the database was static. Been doing startups for 20 years. And persistence models are definitely dynamic in those.

      W Offline
      W Offline
      W Balboos GHB
      wrote on last edited by
      #42

      jschell wrote:

      Which means, after a while, that you are going to have a lot of conditional code.

      Actually, no. The idea is to have the conditional during the transition and then remove it. Even if you only get around to removing it when you put in the next conditional during the next round of changes. Note (back to the thread start) that they wanted to shut things off after some future point in time. The conditional methodology is a work-around and doesn't need any date setting. It just keeps working, and, as updates are done the just work. However . . . Accumulating conditionals, if that is what colored your comments, is something with which I agree. It all becomes an ugly patchwork and is bound to collapse.

      Ravings en masse^

      "The difference between genius and stupidity is that genius has its limits." - Albert Einstein

      "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

      J 1 Reply Last reply
      0
      • W W Balboos GHB

        jschell wrote:

        Which means, after a while, that you are going to have a lot of conditional code.

        Actually, no. The idea is to have the conditional during the transition and then remove it. Even if you only get around to removing it when you put in the next conditional during the next round of changes. Note (back to the thread start) that they wanted to shut things off after some future point in time. The conditional methodology is a work-around and doesn't need any date setting. It just keeps working, and, as updates are done the just work. However . . . Accumulating conditionals, if that is what colored your comments, is something with which I agree. It all becomes an ugly patchwork and is bound to collapse.

        Ravings en masse^

        "The difference between genius and stupidity is that genius has its limits." - Albert Einstein

        "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

        J Offline
        J Offline
        jschell
        wrote on last edited by
        #43

        W∴ Balboos wrote:

        The idea is to have the conditional during the transition and then remove it. Even if you only get around to removing it when you put in the next conditional during the next round of changes.

        Which is why I prefer it to be separate. With it embedded in the code you end up with the following problems. 1. How to detect it 2. How to handle things like indexes, constraints 3. What happens if two places need the same update 4. Prioritizing the code removal 5. How to determine that it can be removed.

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups