You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Solution 1: Let the match ID be empty for scrim and manually created matches. It's meaningless anyway when it's fixed to a string, as it won't distinguish any scrim or manual match from another.
Solution 2: If the MySQL plugin is loaded and sees "scrim" or "manual" as a match id; override it to empty string, which triggers the auto-insert logic to generate a new match ID.Edit: This is a bad idea as the match ID is immediately used for writing backup files and such. Approach 1 should work.
Problem: The init series forward sent to MySQL is async, and in that callback, a call to the Get5_SetMatchID native is placed, overriding the match ID. But since this is async, the original empty string is going to be used for everything until that call comes through, which could take quite a while. Not sure what's best here. I might have to look closer at this, but I still believe setting it to an empty string is the better solution for a quick-fix right now.
The text was updated successfully, but these errors were encountered:
@splewis Need your input on this one. I'm not 100% sure of the reasoning behind having a fixed string value as match ID, and as you can see it's a problem.
An obvious solution here is to just always make the MySQL plugin use auto-increment and simply override the match ID. The column has auto-increment anyway, so you are not supposed to specify values for the column at all.
This creates only one problem: The round prelive backup will not have the correct match ID, as it is generated before MySQL can change the Match ID. What we can do is make the native Get5_SetMatchId call WriteBackup. That should fix it, but will of course leave a lingering "scrim" or "manual" prelive backup that will keep being overridden by the last scrim or manual match.
It would appear that the
get5_scrim
andget5_creatematch
commands both set fixed, non-integer match IDs, which cannot be inserted into the MySQL tables if the schemas are what's defined in https://github.com/splewis/get5/blob/master/misc/import_stats.sql.get5/scripting/get5/matchconfig.sp
Lines 1009 to 1018 in 8c5e46a
get5/scripting/get5/matchconfig.sp
Lines 1073 to 1082 in 8c5e46a
get5/scripting/get5_mysqlstats.sp
Lines 93 to 111 in 8c5e46a
Solution 1: Let the match ID be empty for scrim and manually created matches. It's meaningless anyway when it's fixed to a string, as it won't distinguish any scrim or manual match from another.
Solution 2:
If the MySQL plugin is loaded and sees "scrim" or "manual" as a match id; override it to empty string, which triggers the auto-insert logic to generate a new match ID.Edit: This is a bad idea as the match ID is immediately used for writing backup files and such. Approach 1 should work.Problem: The init series forward sent to MySQL is async, and in that callback, a call to the
Get5_SetMatchID
native is placed, overriding the match ID. But since this is async, the original empty string is going to be used for everything until that call comes through, which could take quite a while. Not sure what's best here. I might have to look closer at this, but I still believe setting it to an empty string is the better solution for a quick-fix right now.The text was updated successfully, but these errors were encountered: