[Mangos Zero] Impressions of a fresh Zero install

[Olion]

Experienced by building the 32-bit project on Win7 x64 with Cmake 3.4.3, mysql 5.1.55 (community server), openssl 1.0.1g, MS VS 2013 12.0.31101.00 Upd4.

The whole setup went as usual. I did not use EasyBuild and did not drop my old realmd DB. Then I decided to check DB versions.

The world DB has strange enough records:

21,1,0,'revision_refactor',''
21,1,11,'Fix last startup errors','server - fix last startup errors'

Well, I wasn't interested in the fate of 21-1-{1..10} updates concentrating on the possibility to start the server, since the revision.h file required 21-2-3. Applying the updates manually with SQLyog one-by-one, I got no further than 21-1-21. For a reason unknown to me, the SQL client fails to apply long updates through "Execute SQL file..." interface option, while the same update copypasted into the client command window runs fine. Note the similar behaviour of Navicat too.

When an update is applied through the interface command, there is no diagnostic output at all. From the command window, I see only `description` output value which is useless (see for example a lot of recent dbdocs updates with - wow! - the same description field). I say constantly that the transactional updates are evil...

Checking the two other DB versions, I got an issue with older realm DB about dbdocs table structure. It will not be encountered at a full fresh install.

I doubt that a user can solve this DB mess on his own. Anyway, I have the following propositions:

1. The full update history must be kept in the db_version tables since the latest major release. In our case it would be 21-1-0 to 21-1-11.
   
2. Rethink what the scheme is better for a user: either to apply all DB updates from the Updates/Relxx/ folder, or to find the missing ones by unsuccesfully starting mangosd. Note that he also can miss some minor (content) updates in the latter case.
   
3. Keep an eye on other projects (One, Two) when updating realmd submodule and especially realmd DB. It is a waste work, but the whole repo structure implies necessity of it.
   
4. It is barely needed to change the `db_version`.`structure` field for dbdoc structrure updates since the tables are not used by the core. The users are not interested in these tables, but they are interested in the starting server.
   
5. The hosting service must support the "Downloads" section for any project. Since github does not, it will be excellent to have the binaries required by EasyBuild (btw why do not use network install?) as well as EasyBuild itself as a submodule. This will greatly reduce the core repo size, and the most of devs are not meant to change anything under win/ folder. (Also I will be happy to drop that submodule locally ).
   
6. (Optional) Remember me why we are keeping transactional DB updates after finished transition to the new (Foe's) update numbering system. Also think about reapplicability of introduced SQL updates.
   

No need to repeat that the admins have to enforce the accepted policies checking the PRs before merges. Despite that would mean rejecting 50 to 80% of the commits (well, may be this statistics was improved a bit lately).

[antz]

Thanks for the 'clean' test. I will look into the issue of applying the updates first before responding to the test of your points.

Just so I can emulate your issues, can exactly are you applying 21.1.21 when it fails ?

[Olion]

Just so I can emulate your issues, can exactly are you applying 21.1.21 when it fails ?

Not only 21-1-22 fails with the graphical SQL clients mentioned above, but any long update (22-25). I have applied them by copypasting the file content into the SQLyog command window and executing the set (got few warnings). The worst thing is the absence of any diagnostic output.

P.S. SQLyog Ult v10.42, Navicat Prem v10.1.6 are tested.