For some reason Drupal core has schema_version column as smallint, which limits it to 32767 max. According to current convention first digit is reserved for Drupal core, second 1 or 2 for project releases. Currently this means numbers would be 7AAB (7AABB is over the limit) where A is project release, and B is intra-release version. Not good. Another possibility would be to have 7ABB versions but that would mean your project has only 10 releases which is very limiting too.
Since it is unlikely that there will be thousands modules/themes installed, having the column as normal int should not hurt anyone.
This could qualify as feature request but I think it could be bug too because one could reach such limit suddenly, with further updates not working. Also I think it's important to think about future Drupal releases which will be over 1 digit.
| Comment | File | Size | Author |
|---|---|---|---|
| d7_schema_version.patch | 1.4 KB | crea |
Comments
Comment #1
mikey_p commentedActually the standard is ABCC. Where A is the Drupal version, B is the major of the module and CC is the minor. And no, we don't support having 10 versions of your module for 1 version of core. If you have more than 10 versions of your module for 1 version of Drupal core, you're probably doing something wrong.
All that aside, I don't see any problem with the change other than it's a huge API change and we need document and then convert everything from that major of Drupal onward as ABBCC and instruct users to always use 2 digits for their major. i.e. mymodule_update_70101 for the first update to my module 7x-1.1 .
Comment #2
crea commentedI'm not just talking about contributed modules. When drupal is used in big sites, there is always a "project module" which serves as container for project updates. Big sites can have hundreds of updates, especially if they are actively developed. Having either just 10 major project releases or 10 intra-release fixes is very limiting.
Comment #3
mikey_p commentedIf it's a custom, site specific module, then you don't have to worry about tagged releases or strictly keeping the numbering standard. In that case you have 1000 items to work with if you stick with the first being the correct version of Drupal, but really nothing stops you from using hook_update_1, hook_update_2 in a site specific module. I'm not opposed to this patch, but I don't think it's much of an issue, and it should probably be bumped to 8.x since alot of contrib developers have already started to update their code for 7.x.
Comment #4
neochief commentedHey Michael, thanks for your feedback.
We are actually developing Drupal distribution for one of the enterprise sectors and facing the same issue. We do all of the updates through hook_updates, and we need to keep a lot of project modules with only Drupal version, but also the version of distribution (even if we get rid of Drupal digits, problem remains the same). For instance, if we develop feature for our 2.13 version of distribution, which is based on Drupal 7, and we have over 100 updates sometimes, we need to call update hooks 7213100 (7AAABBB), which leaves us in a trouble. We can skip Drupal version, but we will still be in trouble with 213100 (AAABBB).
As Drupal distributions are on the rise, and they'll be especially popular with D7, it shall become a real problem soon. This change shouldn't really affect anything. We do not change the procedure of naming hooks, we do not really modify the scheme. We just make this number bigger.
Comment #5
crea commentedTurning 7ABB scheme into 7ABBBB+ is still big improvement. There's no need to change the API/docs, just raising the limit would be enough.
Comment #6
thedavidmeister commented100 updates is definitely limiting in many situations where a database needs to be maintained over a long period of time and there may need to be many changes deployed. This has become a very standard workflow for many organisations.
Other frameworks don't simply use an integer 0-99 like Drupal does, they drop in a timestamp - check out Ruby and Symfony database migrations, for example.
Ideally, I assume we'd want either our update hooks to look much more like Doctrine Migrations, or remove them altogether in favour of Doctrine Migrations. I also assume this has been discussed at length somewhere, so if anyone has a link to another issue, please update this thread :)
Comment #15
catchThis is now stored in key/value, which has no such constraint. See UpdateHookRegistry