-1

In my model a user entity has three attributes : ID, name, hasBoyfriend. I want now to change hasBoyfriend to boyFriendsNames which is an array of names . The user entity is used by many services.

The question is: Should I keep the deprecated hasBoyfriend attribute and gradually remove it Or should I remove it completely and force all current services to use the new model, which means more development time ? What is the best practice on these kind of matters ? How is this process called ? Any resource in that matter would be greatly appreciated .

For the picky reader I use a database and code(java, javascript etc) for interacting with the database .

Improve this question
4
  • 4
    There is no way to answer this question, as it depends on a specific case. Sometimes it would make sense to remove the old attribute; other times, it would be necessary to keep it.
    – Arseni Mourzenko
    Commented Feb 8, 2021 at 14:17
  • Which parameters affect it ? When does it make sense to keep the old attribute and when to not keep it ? Discussing these parameters might be the answer
    – Cap Barracudas
    Commented Feb 8, 2021 at 14:21
  • 1
    It makes sense to keep the old attribute when migrating the code which depends on it is either impossible or too complex. This is not really a constructive discussion about some parameters which would determine what should you do in a given case.
    – Arseni Mourzenko
    Commented Feb 8, 2021 at 17:28
  • I see .. So you suggest when it is not very difficult to migrate the code and not try to gradually manage the process somehow . Cool !
    – Cap Barracudas
    Commented Feb 8, 2021 at 17:44

2 Answers 2

Reset to default
2

In principe you should have build your code on well encapsulated domain objects. In this case:

  • The only code that would rely on database attributes would be in the persistence layer/data access layer/data source layer (depending on your architectural model).
  • You could change the database attributes as you want and limit the propagation of changes to the rest of the code (everywhere else, the code would just invoke hasPartner() regardless if this just returns a hasBoyFriend attribute or if it checks that boyFriendsNames is not an empty set.
  • The only constraint for removing the hasBoyFreind attribute would be that you have all the related names available. If the code is well encapsulated, you could btw easily use an "Unknown" name added in the set if the names are not yet known, and add a isPartnerUnknown() method, to provide the appropriate bahavior when hasPartner() is true but the name is yet unknown and neesds completion.

If it's too late and the database attribute already pouted all your code, then use FrustatedWithFormDesigner's solution. THe latest bullet can be adapted to his/her solution to give more flexibility.

Improve this answer
1

The "nice" thing to do is to post a news item on your website (or whatever channel you use to communicate to the users of your service) that the hasBoyfriend attribute will eventually be replaced by the boyFriendsNames attribute. Give your users a timeline for when this change will occur so they can modify their code accordingly. There should probably be a period of time where both attributes exist, in case some users haven't finished the transition yet. It's more work, but your users will appreciate it.

Improve this answer

Your Answer

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

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