2

The project I'm working on has a code dependency on a TeamNames enum. The problem with this is that the project needs to be recompiled and redeployed on any addition/deletion in TeamNames. How can I remove this dependency?

I have come up with 2 possible solutions:

  1. Accepting each and every TeamName as a String field. The issue with this is possible garbage values being entered by the user.
  2. Storing TeamNames in a DB and validating when the user enters the name. Creating a single-column table in a DB just for team names would be overkill IMO.

What alternatives could I look into, to find a better approach to solving this?

5
  • 1
    Are you using "Team" in the sense of "team of coworkers" or in the sense of a sports team? Jul 14, 2021 at 12:28
  • If team is something that can be defined by the user, storing that in database is perfectly fine, because it's operational data and should not be present directly as array of values in code.
    – smajlo
    Jul 14, 2021 at 13:27
  • So is the issue that it's hard to re-compile and re-deploy the application? If so that indicates a likely problem somewhere in the overall development or release process, possibly in the CI/CD pipeline. The need to produce small, low-risk, lightweight changes tend to be common on a lot of projects, so ideally you would have a build/deployment/release process which allows a team to rapidly push those changes out with very little effort, which then means that small changes such as those to your enum should cease to be a problem. Jul 14, 2021 at 13:28
  • enums are best for static data. Otherwise unique identifiers in persistent storage (like a database) will do. Jul 14, 2021 at 17:00
  • You are absolutely right. I'm working on an old codebase that, unfortunately, has hardcoded operational data. I'm trying to migrate it with the least number of changes possible.
    – NiceOne
    Jul 15, 2021 at 4:52

4 Answers 4

11

Creating a single-column table in a DB just for team names would be overkill IMO.

Create a proper Teams table then. With a key and Name and maybe some other properties that a team may have. This can be shown to the user as a select box. The user will see the name, the application will use the key for all its operations.

1
  • Thank you, this is what I've decided to go ahead with. It can also be extended in the future if there's more Team level data to be added.
    – NiceOne
    Jul 15, 2021 at 4:53
3

The project I'm working on has a code dependency on a TeamNames enum.

So you have data that relates to each Team.

That says to me that Team is a data Entity that you care about and, since a Team can probably exist in its own right, that means it should have its own table.

The problem with this is that the project needs to be recompiled and redeployed on any addition/deletion in TeamNames.

Adding and removing rows from a table is far easier than hacking about, changing [lots of] code that is dependent on an Enum. Also, you can almost guarantee that, someday, someone will want to add a Team whose name contains characters that are illegal in a Java identifier. Database columns are far more "forgiving".

Creating a single-column table in a DB just for team names would be overkill IMO.

I would wager that, in a fairly short period of time, you'll find other data attributes that pertain directly to each Team and you'll add them. Even if you don't, having these values in a table is still the best approach.

1
  • The part about illegal characters in a Java identifier is something I had not thought of. Thanks for that!
    – NiceOne
    Jul 15, 2021 at 4:54
1

From your post it is not clear whether team name is the name of a team member or of a team role.

If team name refers to a team role which might change on the request of the user, but not too frequently you could use an array of strings and store the array in a property. The next step would be to decide how to maintain the property file. You can change it manually or add an update function.

If instead team name refers to names of team members that might change more frequently the DB solution even for a few data would be more flexible, but it will require extra work to add all the update functionalities.

0

Without doubt an enum is a closed value domain, and also a bottle neck on maintenance, like rebuilds and vcs merge conflicts and so on.

  1. An interface for team name typed constants. For different groups could define a child interface (Responsibility principle). Packing this value domain in a type is good practice. So there could be a class Team (?).

  2. Database. Hmm, does a team not more or less corresponds to a group, comparable with a authentication user, a Principal. Maybe you should look for those kind of solutions. That is if the usage involves roles, rights. Some solutions are very basic and open ended. So not too much effort. The user/group realm could for instance be XML based.

It is a matter of the intended scope. (1) is simpler - no extra knowledge acquisition, (2) more ambitious - one could start with annotations etcetera.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.