11 votes

Fortnightly Programming Q&A Thread

General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.

Don't forget to format your code using the triple backticks or tildes:

Here is my schema:

```sql
CREATE TABLE article_to_warehouse (
  article_id   INTEGER
, warehouse_id INTEGER
)
;
```

How do I add a `UNIQUE` constraint?

14 comments

  1. [9]
    krg
    Link
    For people that are working on projects solo and using version control... do you follow the convention of creating a branch for each "feature" you're working on? Or does everything happen on the...

    For people that are working on projects solo and using version control... do you follow the convention of creating a branch for each "feature" you're working on? Or does everything happen on the master branch, for you? All of my projects are pretty much solo, at the moment, but I'm still trying to think about and follow best-practices.

    4 votes
    1. Emerald_Knight
      Link Parent
      Feature branches are a good idea even for a solo project. Ideally you would commit smaller changes as you progress and then merge the final result once the feature itself is completed and...

      Feature branches are a good idea even for a solo project. Ideally you would commit smaller changes as you progress and then merge the final result once the feature itself is completed and validated. If at any point in the middle of these smaller commits you decide that you don't want the feature, are unable to implement it due to some fundamental limitation, or need to switch to a higher priority task, you don't want to have to manually roll back these changes in the master branch. If you have it done in a feature branch then you can just abandon the branch and optionally return to it later.

      In other words, feature branches give you the freedom to abandon or postpone changes while still keeping them tracked via version control. Definitely use them.

      6 votes
    2. Bauke
      Link Parent
      Alongside what Emerald_Knight has mentioned, git's stash feature can also come in very handy. Especially if you don't want the overhead of managing branches.

      Alongside what Emerald_Knight has mentioned, git's stash feature can also come in very handy. Especially if you don't want the overhead of managing branches.

      4 votes
    3. Deimos
      (edited )
      Link Parent
      I generally only create a branch if it's a larger change that's going to be a longer-term project, or something that I otherwise expect could be interrupted before I finish it. If it's the only...

      I generally only create a branch if it's a larger change that's going to be a longer-term project, or something that I otherwise expect could be interrupted before I finish it. If it's the only thing that I'm working on and I'll probably finish it within a couple of days, there's not really any significant benefit from a branch.

      Even if I do end up needing it to be in a branch after I've started, it only takes a couple commands to "move" it, by just creating a branch off the master state and then resetting master back to the previous commit. So it's really not a big deal either way, you can always switch.

      3 votes
    4. thistle
      Link Parent
      I sometimes do, but I find that they become useless, because I do all the work on the feature in one go. Now, on the other hand, if I were to make changes to master while working on this feature,...

      I sometimes do, but I find that they become useless, because I do all the work on the feature in one go. Now, on the other hand, if I were to make changes to master while working on this feature, and didn't want to include these changes in the feature branch, this idea would be useful. But that never happens for me.

      2 votes
    5. aphoenix
      Link Parent
      I think that the best answer to this for small projects is to do what feels best to your brain. If small features live in branches, and that's the way you think (it's the way I think) then it's a...

      I think that the best answer to this for small projects is to do what feels best to your brain. If small features live in branches, and that's the way you think (it's the way I think) then it's a good idea to make branches for things. If that feels like unnecessary work, then don't do it. The important thing to remember is that "features go in branches" is a guideline because for a non-trivial number of developers, that actually aids development; it's not done just to impose nonsense rules on people. But it's also just as important to recognize if that is something that resonates with how you do your work; the most important thing is that workflow is effective.

      A lot of people on both sides of this issue forget that the only important thing is that workflows are effective. They end up loving the workflow qua workflow, which is dangerously stupid.

      There are a variety of reasons that I find features in branches effective, and why I tend to do pull requests for my own work, even if I'm the one reviewing them. I like to see what a patch in its entirety is doing to a codebase. It's possible to do this without using a branch and a PR, but using a PR makes it trivial to do this review. Before merging something in, I like having the "okay, now actually review all the things you actually did" step. I also tend to work on multiple things concurrently; I might be working on Feature A, which is not trivial, and have an idea for Feature B. I'll switch to different branch, and outline what I'm planning, then switch back. It's an organizational tool for me.

      2 votes
    6. DataWraith
      Link Parent
      I find that using feature branches adds friction to the development process, so I avoid them for small projects and spikes. There are various ways to reduce that friction through automation (e.g....

      I find that using feature branches adds friction to the development process, so I avoid them for small projects and spikes. There are various ways to reduce that friction through automation (e.g. git-town), but even then it's not worth it for personal projects, so those just get developed on the main branch.

      I do use feature branches for professional work (even when solo), because often several different features will be in flight at any one time, and having them separate makes things much simpler when it comes to selectively deploying to staging or production environments.

      I guess I could use feature-toggles instead of different branches (which is what Trunk-based development advocates), but that comes with its own headaches and is mostly meant for many-person projects.

      1 vote
    7. viridian
      Link Parent
      For super small projects I work directly off of master, for larger ones I just go master > develop > sandbox and merge up as needed, and split off big features from develop when needed.

      For super small projects I work directly off of master, for larger ones I just go master > develop > sandbox and merge up as needed, and split off big features from develop when needed.

      1 vote
    8. Bwerf
      Link Parent
      Depends, mostly only when I'm trying to develop two different features in parallel, which happens if one of them is large, or sometimes when I'm switching computers and don't want to commit and...

      Depends, mostly only when I'm trying to develop two different features in parallel, which happens if one of them is large, or sometimes when I'm switching computers and don't want to commit and push for some reason.

      1 vote
  2. [2]
    Bwerf
    Link
    Just started learning rust and I'm wondering what the recommended way of indexing the same data in several different ways is. I want the data both in a linear fashion on disc (using Vec atm) and...

    Just started learning rust and I'm wondering what the recommended way of indexing the same data in several different ways is. I want the data both in a linear fashion on disc (using Vec atm) and in a recursive fashion for easy traversing. How do you handle referring to the same item in two different places? I tried putting the data in the tree hierarchy as references, while the actual objects are stored in the linear storage for faster iterations, but I need to do lots and lots of lifetime hints everywhere, am I going about it in the correct way? I want everything to have the same end of life, i.e. it should stick around until the program shuts down.

    1 vote
    1. whbboyd
      Link Parent
      (Very late response, sorry!) A commonly-used approach to this sort of problem is, rather than storing references, to place your actual items in a Vec and then store int indexes into that Vec in...

      (Very late response, sorry!)

      A commonly-used approach to this sort of problem is, rather than storing references, to place your actual items in a Vec and then store int indexes into that Vec in your other structures. This is definitely not a perfect solution (you give up all ability for the compiler to check the validity of your indexes, because they're just ints, for instance), but completely sidesteps lifetime issues.

  3. [3]
    Bwerf
    Link
    As a comment to OP, sql dialects vary a lot, what database are you using? (Assuming it was a genuine question and not just an example =) )

    As a comment to OP, sql dialects vary a lot, what database are you using? (Assuming it was a genuine question and not just an example =) )

    1. [2]
      Bauke
      Link Parent
      This is a scheduled topic that is automatically posted by Tildes itself, it's just an example. :P

      This is a scheduled topic that is automatically posted by Tildes itself, it's just an example. :P

      2 votes
      1. Bwerf
        Link Parent
        Haha, perfect. I thought it sounded like something that'd be very easy to look up yourself =)

        Haha, perfect. I thought it sounded like something that'd be very easy to look up yourself =)

        1 vote