| .. |
|
AgentPrefs.migrations
|
6f71d5c2c6
Support for Linden AgentPreferences capability and friends (UpdateAgentLanguage and UpdateAgentInformation) and Mantis #7157
|
%!s(int64=9) %!d(string=hai) anos |
|
AssetStore.migrations
|
134e94a7e9
Flatten migrations for MySQL.
|
%!s(int64=8) %!d(string=hai) anos |
|
AuthStore.migrations
|
134e94a7e9
Flatten migrations for MySQL.
|
%!s(int64=8) %!d(string=hai) anos |
|
Avatar.migrations
|
2cfe848ceb
Correct case in the names of the Avatar and Friends tables
|
%!s(int64=8) %!d(string=hai) anos |
|
EstateStore.migrations
|
0d76635113
do store a new flag on region db
|
%!s(int64=4) %!d(string=hai) anos |
|
FSAssetStore.migrations
|
f3f748ed11
Bringing FSAssets more inline with current OpenSim standards. * If no connection string found in assets config, fallback to using default database config * Create database storage interface to allow other db connectors to be written at some point * Add MySQL migrations file to create the initial db table * Added new config option named DaysBetweenAccessTimeUpdates to reduce db load by only updating access times when fetching assets if the last access time was over the threshold. This idea was taken from XAssets service. * Change log message headers to indicate FS assets is the source not just assets
|
%!s(int64=9) %!d(string=hai) anos |
|
FriendsStore.migrations
|
51e69e8b4f
a few more tables that may blowup on utf8mb4 and need no more than latin1
|
%!s(int64=3) %!d(string=hai) anos |
|
GridStore.migrations
|
134e94a7e9
Flatten migrations for MySQL.
|
%!s(int64=8) %!d(string=hai) anos |
|
GridUserStore.migrations
|
9533217d82
change some mysql tables and columns character sets, this is close to patch at mantis 8707, but that is not correct. This should have no impact on current dbs. Many of those are now too large to do this change automaticl,, but they should. Some columns as utf8 (4 bytes in future) are pure waste of space, in fact some are used as indexes and can violate max index size. Namelly on groups V2, reason why we are forced to use utf8mb3 mostly likely to be dropped by new mysql/maria versions
|
%!s(int64=4) %!d(string=hai) anos |
|
HGTravelStore.migrations
|
9533217d82
change some mysql tables and columns character sets, this is close to patch at mantis 8707, but that is not correct. This should have no impact on current dbs. Many of those are now too large to do this change automaticl,, but they should. Some columns as utf8 (4 bytes in future) are pure waste of space, in fact some are used as indexes and can violate max index size. Namelly on groups V2, reason why we are forced to use utf8mb3 mostly likely to be dropped by new mysql/maria versions
|
%!s(int64=4) %!d(string=hai) anos |
|
IM_Store.migrations
|
53fe204eed
Create all tables ad InnoDB by default
|
%!s(int64=7) %!d(string=hai) anos |
|
InventoryStore.migrations
|
134e94a7e9
Flatten migrations for MySQL.
|
%!s(int64=8) %!d(string=hai) anos |
|
LogStore.migrations
|
ee713cb253
Converted MySQL migration history to the new format
|
%!s(int64=14) %!d(string=hai) anos |
|
MuteListStore.migrations
|
9533217d82
change some mysql tables and columns character sets, this is close to patch at mantis 8707, but that is not correct. This should have no impact on current dbs. Many of those are now too large to do this change automaticl,, but they should. Some columns as utf8 (4 bytes in future) are pure waste of space, in fact some are used as indexes and can violate max index size. Namelly on groups V2, reason why we are forced to use utf8mb3 mostly likely to be dropped by new mysql/maria versions
|
%!s(int64=4) %!d(string=hai) anos |
|
Presence.migrations
|
51e69e8b4f
a few more tables that may blowup on utf8mb4 and need no more than latin1
|
%!s(int64=3) %!d(string=hai) anos |
|
RegionStore.migrations
|
44c90bf294
misspell all across the board
|
%!s(int64=4) %!d(string=hai) anos |
|
UserAccount.migrations
|
9533217d82
change some mysql tables and columns character sets, this is close to patch at mantis 8707, but that is not correct. This should have no impact on current dbs. Many of those are now too large to do this change automaticl,, but they should. Some columns as utf8 (4 bytes in future) are pure waste of space, in fact some are used as indexes and can violate max index size. Namelly on groups V2, reason why we are forced to use utf8mb3 mostly likely to be dropped by new mysql/maria versions
|
%!s(int64=4) %!d(string=hai) anos |
|
UserProfiles.migrations
|
53fe204eed
Create all tables ad InnoDB by default
|
%!s(int64=7) %!d(string=hai) anos |
|
XAssetStore.migrations
|
d7b45a3ed2
Alter the migrations so that it is a no-op as the columns are unused and the operation is very expensive
|
%!s(int64=9) %!d(string=hai) anos |
|
os_groups_Store.migrations
|
9533217d82
change some mysql tables and columns character sets, this is close to patch at mantis 8707, but that is not correct. This should have no impact on current dbs. Many of those are now too large to do this change automaticl,, but they should. Some columns as utf8 (4 bytes in future) are pure waste of space, in fact some are used as indexes and can violate max index size. Namelly on groups V2, reason why we are forced to use utf8mb3 mostly likely to be dropped by new mysql/maria versions
|
%!s(int64=4) %!d(string=hai) anos |
UbitUmarov
51e69e8b4f
a few more tables that may blowup on utf8mb4 and need no more than latin1