zeripath fcfbab99fc Set the name Mapper in migrations (#14526) ... Migrations currently uses the default Xorm mapper which is not the same as the mapper Gitea actually uses. This means that there is a difference between the struct parsing and mapping to database tables in migrations as compared to normal Sync2. This was the cause for the catastrophic problem in v168 - untagged fields are not mapped in the same way in migrations as compared to outside of migrations. This is also likely the cause of some weird subtle failures in other migrations as any untagged field may not be being mapped exactly the same way. This PR suggests that we ensure that the mapper is set at the start of the migrations code - but also enforces a strict clean mapper between each migration. Signed-off-by: Andrew Thornton <art27@cantab.net>		2021-01-30 16:24:25 +01:00
..
migrations.go
v70.go
v71.go
v72.go
v73.go
v74.go
v75.go
v76.go
v77.go
v78.go
v79.go
v80.go
v81.go
v82.go
v83.go
v84.go
v85.go
v86.go
v87.go
v88.go
v89.go
v90.go
v91.go
v92.go
v93.go
v94.go
v95.go
v96.go
v97.go
v98.go
v99.go
v100.go
v101.go
v102.go
v103.go
v104.go
v105.go
v106.go
v107.go
v108.go
v109.go
v110.go
v111.go
v112.go
v113.go
v114.go
v115.go
v116.go
v117.go
v118.go
v119.go
v120.go
v121.go
v122.go
v123.go
v124.go
v125.go
v126.go
v127.go
v128.go
v129.go
v130.go
v131.go
v132.go
v133.go
v134.go
v135.go
v136.go
v137.go
v138.go
v139.go
v140.go
v141.go
v142.go
v143.go
v144.go
v145.go
v146.go
v147.go
v148.go
v149.go
v150.go
v151.go
v152.go
v153.go
v154.go
v155.go
v156.go
v157.go
v158.go
v159.go
v160.go
v161.go
v162.go
v163.go
v164.go
v165.go
v166.go
v167.go
v168.go