-1

Lets say you have a Database, and a Data Access Layer (DAL)

The DAL will be consumed by a various number of products which access the Database.

As time goes on, you add new fields and tables to the Database, and therefore update the DAL from version 1.0.0 to version 1.0.1. Everything is fine and nice :)

Your team decide that later down the line in version 1.0.13 that the field is no longer required, so you delete the field from the database, and increment the DAL to 1.0.14.

This will break versions 1.0.1, 1.0.2, 1.0.3... and so on.

Another example:

Say you have a field called streetName in the Database, and the DAL is at 1.0.0, but later, you change the street name field to addressLine1, and increment the version of the DAL to 2.0.0. What would happen to 1.0.0? It clearly isn't going to work anymore because it cannot find the streetName field in the Database

How does one solve this problem? Multiple Databases per DAL version? Is this even the correct direction of approach?

Tersosauros
  • 768
  • 3
  • 19
Dolan
  • 109
  • 5
  • 2
    It's quite simple, don't do versioning on the database level but instead on the API level. – Andy Oct 12 '16 at 09:39
  • please don't **[cross-post](http://meta.stackexchange.com/tags/cross-posting/info "'Cross-posting is frowned upon...'")**: http://stackoverflow.com/questions/39878957/how-to-handle-legacy-versions-of-dal-and-database "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..." – gnat Oct 12 '16 at 09:40
  • 1
    Sorry, i deleted the original. I posted it here because I believe StackOverflow may have been the wrong forum to post the question. – Dolan Oct 12 '16 at 09:42
  • Are you asking about semantic versioning? Breaking changes require a new major version number. So 1.0.14 would become 2.0.0. And it would them be up to the consumers to update their code accordingly. http://semver.org/ – Cerad Oct 12 '16 at 12:16
  • I've added another example in the question. Ok, fine, version `2.0.0` it is, but what about version `1.0.14`? Is this version unusable now? – Dolan Oct 12 '16 at 12:36
  • 1
    Both http://programmers.stackexchange.com/questions/146324/handling-database-schema-changes-when-pushing-new-versions and http://programmers.stackexchange.com/questions/125182/database-migration-upgrade-schema-deployed-on-client-machines seem to deal with specific examples of the problem you describe, where programmers have actually faced this scenario. – Robin James Kerrison Oct 12 '16 at 12:37
  • 1
    Are you talking about a situation where there is more than one business logic layer utilizing a single DAL and you're not able to upgrade both of them along with the DAL? – JeffO Oct 12 '16 at 14:51
  • 1
    You should be using [Semantic Versioning](http://semver.org/) anyway. This would bean 1.0.14 would never exist, as it would make incompatible API changes, it would indeed become 2.0.0. – Tersosauros Oct 18 '16 at 00:12

1 Answers1

2

This is not the correct approach, IMO. The purpose of the DAL is to abstract away any details about storing data. As such it requires a place to store it's data. In your example this is a database with a particular schema.

Now for versioning this, you have to have a database with the correct schema for your DAL. A common approach to achieving this is to include code that knows how to migrate from previous versions to the current version. At a point in your software correct for your situation, you can then check the version of the database and take the necessary actions to get to the current schema. Obviously this could also be a separate tool or a setup procedure of some sort.

To achieve this, it would be easy to store a version number in your database, so you know what version of the schema you are looking at. This approach would allow you to specify what should happen in each scenario, not only with the changes in the schema, but also with the data.