MySQL 8.3.0
Source Code Documentation
dd_version.h
Go to the documentation of this file.
1/* Copyright (c) 2017, 2023, Oracle and/or its affiliates.
2
3 This program is free software; you can redistribute it and/or modify
4 it under the terms of the GNU General Public License, version 2.0,
5 as published by the Free Software Foundation.
6
7 This program is also distributed with certain software (including
8 but not limited to OpenSSL) that is licensed under separate terms,
9 as designated in a particular file or component or in included license
10 documentation. The authors of MySQL hereby grant you an additional
11 permission to link the program and your derivative works with the
12 separately licensed software that they have included with MySQL.
13
14 This program is distributed in the hope that it will be useful,
15 but WITHOUT ANY WARRANTY; without even the implied warranty of
16 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17 GNU General Public License, version 2.0, for more details.
18
19 You should have received a copy of the GNU General Public License
20 along with this program; if not, write to the Free Software
21 Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
22
23#ifndef DD__DD_VERSION_INCLUDED
24#define DD__DD_VERSION_INCLUDED
25
26#include "mysql_version.h" // MYSQL_VERSION_ID
27
28/**
29 @file sql/dd/dd_version.h
30 Data dictionary version.
31*/
32
33/**
34 The version of the current data dictionary table definitions.
35
36 This version number is stored on disk in the data dictionary. Every time
37 the data dictionary schema structure changes, this version number must
38 change. The table that stores the data dictionary version number is never
39 allowed to change.
40
41 The data dictionary version number is the MySQL server version number
42 of the first MySQL server version that published a given database schema.
43 The format is Mmmdd with M=Major, m=minor, d=dot, so that MySQL 8.0.4 is
44 encoded as 80004. This is the same version numbering scheme as the
45 information schema and performance schema are using.
46
47 When a data dictionary version is made public, the next change to a
48 dictionary table will be associated with the next available MySQL server
49 version number. So if DD version 80004 is made available in MySQL 8.0.4,
50 and 8.0.5 is an MRU with no changes to the DD tables, then the DD version
51 will stay 80004 also in MySQL 8.0.5. If MySQL 9.0.4 is the first GA of
52 9.0, and if there are no changes to the DD tables compared to 8.0.4, then
53 the DD version number will stay 80004 also in MySQL 9.0.4. Then, if there
54 are changes to the DD tables after MySQL 9.0.4, then the new DD version will
55 be 90005. In day to day builds internally, changes to the DD tables may be
56 done incrementally, so there may be different builds having the same DD
57 version number, yet with different DD table definitions.
58
59 Historical version number published in the data dictionary:
60
61
62 1: Published in 8.0.3-RC.
63 ----------------------------------------------------------------------------
64 Introduced in MySQL 8.0.0 by WL#6378. Never published in a GA version.
65 Last changes were:
66
67 - WL#6049: Removed foreign_keys.unique_constraint_id and the corresponding
68 FK constraint, added foreign_keys.unique_constraint_name.
69
70 - Bug#2620373: Added index_stats.cached_time and table_stats.cached_time.
71
72
73 80004: Published in 8.0.4-RC.
74 ----------------------------------------------------------------------------
75 Changes from version 1:
76
77 - WL#9059: Added collation clause for spatial_reference_systems.organization
78
79 - WL#9553: Added new 'options' column to the following DD tables:
80 catalogs, character_sets, collations, column_statistics, events,
81 foreign_keys, resource_groups, routines, schemata,
82 st_spatial_reference_systems, triggers.
83
84 (Other relevant DD tables have this column already: columns,
85 indexes, parameters, tables, tablespaces).
86
87 Also added explicit indexes for foreign keys instead of relying
88 on these to be created implicitly for the following tables/columns:
89 character_sets.default_collation_id, collations.character_set_id,
90 columns.collation_id, columns.srs_id, events.client_collation_id,
91 events.connection_collation_id, events.schema_collation_id,
92 foreign_key_column_usage.column_id, index_column_usage.column_id,
93 index_partitions.index_id, index_partitions.tablespace_id,
94 indexes.tablespace_id, parameters.collation_id,
95 routines.result_collation_id, routines.client_collation_id,
96 routines.connection_collation_id, routines.schema_collation_id,
97 schemata.default.collation_id, table_partitions.tablespace_id,
98 tables.collation_id, tables.tablespace_id, triggers.client_collation_id,
99 triggers.connection_collation_id, triggers.schema_collation_id,
100
101
102 80011: Published in 8.0 GA.
103 ----------------------------------------------------------------------------
104 Changes from version 80004:
105
106 - WL#8383 and WL#9465: Removed obsolete SQL modes from enums in 'events',
107 'routines' and 'triggers'.
108
109 - WL#10774 removed NO_AUTO_CREATE_USER as a valid sql mode value.
110 As a result events, routines and triggers table are updated.
111
112 - Bug#27499518 changed the data type for the column 'hidden' in table
113 'columns' from BOOL to ENUM('Visible', 'SE', 'SQL').
114
115 - Bug#11754608 "MYSQL DOESN'T SHOW WHAT COLLATION WAS USED IF THAT
116 COLLATION IS THE DEFAU"
117 Added a new column 'is_explicit_collation' to the 'columns' DD table.
118
119 - BUG#27309116: Add a new column `external_language` to `mysql`.`routines`
120 and update `information_schema`.`routines` to reflect this column.
121
122 - Bug#27690593: CHANGE TYPE OF MYSQL.DD_PROPERTIES.PROPERTIES.
123 Changed type of 'dd_properties.properties' from MEDIUMTEXT to
124 MEDIUMBLOB.
125
126
127 80012: Published in 8.0.12
128 ----------------------------------------------------------------------------
129 Changes from version 80011:
130
131 - Bug#27745526: Various adjustments to make the DD table definitions
132 in sync with WL#6379.
133
134
135 80013: Published in 8.0.13
136 ----------------------------------------------------------------------------
137 Changes from version 80012:
138
139 - Bug#24741307: add last_checked_for_upgrade column to msyql.tables table
140
141
142 80014: Published in 8.0.14
143 ----------------------------------------------------------------------------
144 Changes from version 80013:
145
146 - Bug#28492272: Synchronize sql_mode in server with that in DD.
147
148
149 80015: Not published. DD version still at 80014 in server 8.0.15.
150 ----------------------------------------------------------------------------
151 No changes from version 80014.
152
153
154 80016: Published in 8.0.16
155 ----------------------------------------------------------------------------
156 Changes from version 80014:
157
158 - WL#929 - CHECK CONSTRAINTS
159 New DD table check_constraints is introduced for the check
160 constraints metadata.
161
162 - WL#12261 adds new mysql.schemata.default_encryption DD column.
163
164 - Bug#29053560 Increases DD column mysql.tablespaces.name length to 268.
165
166 80017: Published in 8.0.17
167 ----------------------------------------------------------------------------
168 Changes from version 80016:
169
170 - WL#12731 adds new mysql.schemata.se_private_data DD column.
171 - WL#12571 Support fully qualified hostnames longer than 60 characters
172 Server metadata table columns size is increased to 255.
173
174 80021: Published in 8.0.21
175 ----------------------------------------------------------------------------
176 Changes from version 80017:
177
178 - WL#13341 adds new columns
179 mysql.tables.engine_attribute
180 mysql.tables.secondary_engine_attribute
181 mysql.columns.engine_attribute
182 mysql.columns.secondary_engine_attribute
183 mysql.indexes.engine_attribute
184 mysql.indexes.secondary_engine_attribute
185 mysql.tablespaces.engine_attribute
186
187 80022: Published in 8.0.22
188 ----------------------------------------------------------------------------
189 Changes from version 80021:
190
191 - Bug#31587625: PERFORMANCE DEGRADATION AFTER WL14073: Adds definer index for
192 mysql.{events, routines, tables, triggers}.
193
194 80023: Current.
195 ----------------------------------------------------------------------------
196 Changes from version 80022:
197
198 - WL#10905 adds new hidden type 'USER' to mysql.columns.hidden column.
199 - Bug#31867653 changes the type of mysql.table_partition_values.list_num from
200 TINYINT to SMALLINT.
201
202 80024: Next DD version number after the previous is public.
203 ----------------------------------------------------------------------------
204 Changes from version 80023:
205 - No changes, this version number is not active yet.
206
207 80200:
208 ----------------------------------------------------------------------------
209 Changes:
210 - WL#14190: Replace old terms in replication SQL commands on the SOURCE
211 > Changes the enum of mysql.events.status to use the correct terminology
212 */
213namespace dd {
214
215static const uint DD_VERSION = 80200;
216static_assert(DD_VERSION <= MYSQL_VERSION_ID,
217 "This release can not use a version number from the future");
218
219/**
220 If a new DD version is published in a MRU, that version may or may not
221 be possible to downgrade to previous MRUs within the same GA. From a
222 technical perspective, we may support downgrade for some types of
223 changes to the DD tables, such as:
224
225 i) Addition of new attributes to a predefined general purpose option-like
226 field.
227 ii) Addition of a column at the end of the table definition.
228 iii) Addition of elements at the end of an enumeration column type.
229 iv) Extension of a VARCHAR field.
230 v) Addition of an index on a column.
231
232 This means we can support downgrade in terms of being able to open the DD
233 tables and read from them. However, additional considerations are relevant
234 in order to determine whether downgrade should be supported or not, e.g.:
235
236 - For changes like i) and iii): In the older version, will invalid entries
237 just be ignored, or will they lead to a failure?
238 - For changes like iv): In the older version, are there buffer sizes that
239 may be insufficient?
240
241 If downgrade is supported, the constant DD_VERSION_MINOR_DOWNGRADE_THRESHOLD
242 should be set to the lowest DD_VERSION that we may downgrade to. If downgrade
243 is not supported at all, then DD_VERSION_MINOR_DOWNGRADE_THRESHOLD should be
244 set to DD_VERSION.
245
246 It has been decided that the default policy for MySQL 8.0 is not to allow
247 downgrade for any minor release. One of the major reasons for this is that
248 this would lead to a huge amount of possible upgrade/downgrade paths with
249 correspondingly complicated and effort demanding QA. Thus, we set this
250 constant to be equal to DD_VERSION to prohibit downgrade attempts. This
251 decision may be relaxed for future releases.
252*/
255 "This release can not use a version number from the future");
256
257/**
258 A new release model supporting Long Term Stability (LTS) and innovation
259 releases is being introduced. The LTS releases will be kept as stable as
260 possible, patch updates will be provided mostly for critical issues.
261 Innovation releases will be released regularly with new features.
262
263 When we start a new major version, e.g. 9.0.0, this is an innovation release.
264 Each consecutive release is a new innovation release where the minor version
265 number is incremented. The last minor version for a given major version is an
266 LTS release, this will normally have minor version 7, e.g. 9.7.0. The LTS
267 release will have regular CPU releases (critical patch update) where the major
268 and minor versions stay unchanged, and only the patch number is incremented
269 (e.g. 9.7.1, 9.7.2 etc.). In parallel with the CPU releases, a new major
270 version will also be released, starting with an incremented major version
271 number (e.g. 10.0.0). In some cases, the innovation releases may also have
272 CPU releases, e.g. 9.1.0, 9.1.1 etc.
273
274 With the release model supporting LTS releases, we will have to support
275 downgrade between patch releases. Normally, there will be no changes in
276 features in a patch release, and the disk image should have a similar format,
277 both in terms of record layout, data dictionary structure, system table
278 definitions, information schema, performance schema, etc. However, there might
279 be situations where changes that are not backwards compatible need to be made
280 within a patch release. For some server artifacts, we already have mechanisms
281 in place to allow older versions to reject a downgrade attempt (e.g. if the
282 data dictionary is changed, the older version will reject the downgrade
283 attempt). For other artifacts, there is no such mechanism. Thus, we introduce
284 the SERVER_DOWNGRADE_THRESHOLD which makes it possible to define how far back
285 the current version should be able to downgrade. On a downgrade attempt,
286 the target version will look at the threshold which has been stored
287 persistently by the actual server that we downgrade from. If the target server
288 version is lower than the threshold, it will reject the downgrade attempt.
289
290 The threshold defaults to 0. This means that downgrade back to the first patch
291 for the given version is possible. E.g. if LTS version 9.7.2 has the threshold
292 defined to 0, downgrades to 9.7.1 and 9.7.0 is possible. Then, if LTS version
293 9.7.3 is released with the threshold set to 9.7.2, then only downgrade to
294 9.7.2 is possible. Downgrades to or from innovation releases are never
295 supported, regardless of the downgrade threshold.
296*/
297constexpr uint SERVER_DOWNGRADE_THRESHOLD = 0;
299 "This release can not use a version number from the future");
300
301/**
302 The new release model explained above will also open the possibility of
303 upgrading to a version that has been released in the past. I.e., we will
304 upgrade from an actual version to a target version with a higher version
305 number, but an earlier (older) GA release date.
306
307 Like for the patch downgrades mentioned above, we already have mechanisms in
308 place to allow older versions to reject an upgrade attempt (e.g. if the data
309 dictionary is changed, the older version will reject the upgrade attempt).
310 For other artifacts, there is no such mechanism. Thus, we introduce the
311 SERVER_UPGRADE_THRESHOLD which makes it possible to define how far back
312 the current version should be able to upgrade. On an upgrade attempt, the
313 target version will look at the threshold which has been stored persistently
314 by the actual server that we upgrade from. If the target server version is
315 lower than the threshold, it will reject the upgrade attempt.
316
317 The threshold defaults to 0. This means that for upgrades to any higher
318 version is possible (unless prohibited by other rules). E.g. if LTS version
319 9.7.2 has the threshold defined to 0, upgrades to 10.0.0, 10.1.0 etc. is
320 possible. Then, if LTS version 9.7.3 is released with the upgrade threshold
321 set to 10.2.0, then upograde from 9.7.3 is possible only to 10.2.0 or higher.
322*/
323constexpr uint SERVER_UPGRADE_THRESHOLD = 0;
324
325} // namespace dd
326
327#endif /* DD__DD_VERSION_INCLUDED */
#define MYSQL_VERSION_ID
Definition: mysql_version.h:15
The version of the current data dictionary table definitions.
Definition: dictionary_client.h:42
static const uint DD_VERSION
Definition: dd_version.h:215
static const uint DD_VERSION_MINOR_DOWNGRADE_THRESHOLD
If a new DD version is published in a MRU, that version may or may not be possible to downgrade to pr...
Definition: dd_version.h:253
constexpr uint SERVER_UPGRADE_THRESHOLD
The new release model explained above will also open the possibility of upgrading to a version that h...
Definition: dd_version.h:323
constexpr uint SERVER_DOWNGRADE_THRESHOLD
A new release model supporting Long Term Stability (LTS) and innovation releases is being introduced.
Definition: dd_version.h:297