Refractor/simplify with column renderer

[scoufal]

Unifikace zobrazení tabulek, kromě finančních.

Používá defaultní předefinovatelné IColumnHeaderRenderer a IColumnContentRenderer
Pro oddělování v tabulkách slouží IRowTextPainter a IBreakRowDetector

Část tabulek je refraktorována, zvláště ty které obsahují Race Capacity Limit.

Tabulky se skrytými roky nepoužívalí class jako filter ale data-group attribut.

PR 28 zahrnuje i PR 27 feature Race Capacity limit

[arnost00]

PR 28 zahrnuje i PR 27 feature Race Capacity limit

Ok. Tak uz to chapu, proc je to 2x

[arnost00]

Jeste jsem si vsiml ze sloupec "Účast" (Přihlášeno/Kapacita) se vyskytuje pouze v prihlaskach jednotlivce, nemel by se vyskytovat i v tabulkach pro prihlasky Trenera a Prihlasovatele ?
A to ani nemluvim ze v prihlaskach po jednom pro Trenera a Prihlasovatele se take zadna kapacita nezobrazuje ... to ma nejaky duvod ze je to jen v zakladnich prihlaskach ?

A trosku jsem se pri spojeni PR27 a PR28 do toho zamotal - tohle asi primarne melo byt u PR #27

[arnost00]

Jinak se zatim zda ze se to chova ocekavane. Nove tridy na tabulky snad casem take prostuduji.

[scoufal]

PR #27 a PR#28 jsou podmíněné historicky.

PR #27 by požadavek od organizátora limitovaných tréningů. Implementovaný v minimlizované variantě. Pro integraci do dalších tabulek by změny musely být kopírovány a tak jsem vytvořil PR #28 , abych to nemusel dělat pořád dokola. Jenže nebylo jasné jestli má naději na přijmutí, když je to koncepcionální změna.

[arnost00]

@xkenia koukni prosim na SQL dotaz v common_race.inc.php radek 521.

Me se rozvinul pri testech do :

SELECT id_zavod, COUNT(*) AS prihlaseno FROM tst2_zavxus WHERE id_zavod IN (453,511,513,522,514,523,520,518,527,524,539,542,538,530,532,537,531,540,541,533,550,534,543,544,535,545,547,546,548,549,572,536,553,554,555,557,556,558,559,560,552,562,563,565,564,567,566,568,551,521,571,569,570,576,577,584,578,579,582,585,583,586,587,580,581,588,590,589,591,592,594,595,596,597,599,601,600,598,593,602,603,604,628,629,630,631,632,633,634,635,636,605,607,606,637,609,615,610,638,611,616,617,612,618,619,620,621,622,613,623,624,625,626,627,614,639,640,642,641,643,644,647,608,646,645,648,649,650,651,656,657,658,652,659,664,663,661,660,653,654,655,662,665,666,667,668,669,703,671,672,673,675,674,676,677,678,704,679,706,680,681,682,684,683,685,689,690,686,691,693,692,695,696,697,694,698,688,687,699,700,701,707,708,710,709,705,711,713,712,714,715,702,716,717,718,719,722,723,725,724,720,726,721,727,728,729,730,731,732,733,737,736,734,735,744,743,738,739,761,756,757,740,753,754,755,750,752,751,741,758,759,760,765,766,762,763,764,767,770,769,742,772,773,774,771,768,775,776,785,777,786,779,780,778,745,783,784,782,781,787,788,789,790,791,805,806,807,808,746,809,810,811,812,813,747,814,815,816,792,818,793,817,794,795,796,797,798,799,800,801,802,804,748,803,749,819,842,821,822,823,824,825,826,827,828,829,830,831,832,833,834,849,847,850,851,852,841,848,855,860,853,854,856,859,857,858,843,844,845,872,873,874,861,870,862,871,878,875,879,880,882,881,863,864,876,877,883,866,908,884,865,885,836,837,869,867,868,886,835,887,888,889,899,900,901,902,894,903,904,905,895,890,896,911,891,892,909,838,910,898,840,839,928,933,927,912,929,989,913,931,932,914,990,991,992,993,994,995,996,997,934,935,936,915,978,998,940,999,916,941,937,942,968,938,939,943,969,917,970,971,918,958,959,919,960,961,953,966,967,944,972,973,945,946,962,957,979,920,980,1000,981,982,983,984,922,985,986,921,987,988,947,1001,964,974,965,975,948,976,977,949,923,954,955,956,950,951,924,925,952,926,1005,1002,1003,1004,1006,1007,1010,1009,1012,1008,1013,1028,1027,1029,1014,1030,1031,1047,1048,1015,1042,1043,1044,1045,1032,1016,1017,1046,1049,1033,1050,1026,1051,1052,1034,1053,1055,1054,1035,1060,1062,1061,1063,1056,1057,1058,1059,1036,1083,1081,1064,1077,1018,1080,1019,1065,1082,1020,1084,1066,1067,1069,1068,1070,1037,1071,1072,1073,1074,1075,1021,1038,1078,1079,1039,1040,1022,1023,1041,1024,1085,1091,1101,1126,1125,1086,1092,1025,1102,1093,1094,1103,1095,1097,1087,1098,1088,1104,1171,1099,1105,1100,1089,1183,1170,1148,1169,1090,1168,1124,1173,1127,1184,1106,1128,1139,1161,1107,1172,1154,1149,1185,1186,1187,1188,1129,1115,1108,1155,1162,1156,1163,1130,1116,1109,1140,1164,1131,1150,1165,1151,1132,1110,1159,1160,1133,1111,1141,1142,1134,1175,1117,1176,1177,1174,1178,1118,1179,1180,1119,1181,1112,1182,1113,1157,1166,1158,1167,1114,1143,1144,1135,1145,1152,1153,1136,1189,1120,1137,1146,1147,1138,1121,1190,1122,1123,1191,1197,1198,1199,1200,1201,1217,1192,1219,1211,1221,1218,1193,1222,1223,1194,1226,1224,1227,1228,1229,1230,1231,1261,1284,1262,1286,1289,1195,1263,1196,1264,1287,1265,1285,1203,1266,1315,1232,1316,1267,1318,1290,1288,1321,1268,1233,1234,1269,1235,1291,1236,1270,1204,1225,1271,1292,1319,1205,1293,1237,1238,1239,1320,1272,1240,1241,1273,1294,1274,1242,1244,1246,1243,1245,1247,1295,1296,1275,1248,1249,1276,1250,1251,1297,1305,1206,1216,1306,1307,1308,1207,1208,1309,1209,1304,1322,1323,1324,1325,1303,1311,1210,1312,1277,1326,1313,1314,1278,1252,1253,1279,1254,1256,1298,1255,1280,1257,1327,1258,1281,1299,1212,1282,1259,1260,1335,1300,1301,1213,1214,1302,1215,1328,1329,1330,1331,1332,1333,1334,1342,1337,1350,1336,1351,1338,1349,1341,1356,1339,1357,1340,1352,1343,1360,1353,1354,1358,1362,1361,1369,1359,1344,1370,1345,1368,1423,1346,1363,1424,1371,1364,1347,1383,1381,1382,1348,1365,1366,1416,1421,1384,1415,1367,1403,1373,1402,1398,1386,1387,1374,1375,1392,1399,1393,1400,1376,1377,1394,1395,1404,1405,1406,1407,1408,1418,1409,1410,1411,1412,1413,1414,1390,1391,1396,1397,1378,1401,1388,1389,1379,1380,1419,1420,1426,1425,573,575,574,516,517,1427,519,528,529,1428,1431,1429,1385,1430,1355,512,1096,525,526,670) GROUP BY id_zavod

A teda nevim zda je to optimalni reseni ?

[scoufal]

To je tak, když se to zkouší na malé sadě dat :)

Ten SQL dotaz počítá přihlášené účastníky v závodech, což při celé historii je docela hodně závodů.
Výkonově by bylo asi nejlepší to někde materializovat ve view nebo tabulce, nebo propisovat na definici závodu.

Jednodušší varianta je počítat jen pro závody max 1 rok zpět a/nebo s nastavenou kapacitou.

Co vám připadá lepší?

[arnost00]

To je tak, když se to zkouší na malé sadě dat :)

Ten SQL dotaz počítá přihlášené účastníky v závodech, což při celé historii je docela hodně závodů. Výkonově by bylo asi nejlepší to někde materializovat ve view nebo tabulce, nebo propisovat na definici závodu.

Jednodušší varianta je počítat jen pro závody max 1 rok zpět a/nebo s nastavenou kapacitou.

Co vám připadá lepší?

Ja bych asi hlasoval pro view, ale vetsi specialista na SQL je @xkenia. Tak bych rad kdyby se k tomu vyjadril.

[scoufal]

To je tak, když se to zkouší na malé sadě dat :)
Ten SQL dotaz počítá přihlášené účastníky v závodech, což při celé historii je docela hodně závodů. Výkonově by bylo asi nejlepší to někde materializovat ve view nebo tabulce, nebo propisovat na definici závodu.
Jednodušší varianta je počítat jen pro závody max 1 rok zpět a/nebo s nastavenou kapacitou.
Co vám připadá lepší?

Ja bych asi hlasoval pro view, ale vetsi specialista na SQL je @xkenia. Tak bych rad kdyby se k tomu vyjadril.

Materializovaná view v MariaDB není, dá se udělat aktualizovaný attribut a trigerry. Varianta k posouzení @xkenia je ve větvi
https://github.com/scoufal/members/tree/feature/persistent-count-of-participatns

[arnost00]

Hmmm ja za view povazuju vec co jsme pouzivali uz cca kolem roku 2008, a dodnes to v MariaDb jde vytvorit.
Prikladam priklad SQL dotazu pro vytvoreni view z cca roku 2008 : CREATE OR REPLACE VIEW `eobcz_zbm`.`v_main_payments` AS select `m`.`nazev` AS `nazev`,`u`.`zavod` AS `zavod`,sum(`u`.`vklad`) AS `vklad_za_prihlasene` from (`eobcz_zbm`.`a_main` `m` left join `eobcz_zbm`.`a_users` `u` on((`m`.`zkratka` = substr(`u`.`reg`,1,3)))) where (`u`.`id` is not null) group by `m`.`zkratka`,`u`.`zavod` order by `m`.`zkratka`;
Bylo to v nasem pokusu o prihlaskovy system na zavody (nez se prosadila OBHana :)

Co k tomu rekne @xkenia ?

[arnost00]

Materializovaná view v MariaDB není, dá se udělat aktualizovaný attribut a trigerry. Varianta k posouzení @xkenia je ve větvi https://github.com/scoufal/members/tree/feature/persistent-count-of-participatns

Ono dle ruznych textu neni tento typ view ani v MySQL - tak to ted uz vubec nechapu ... co jsi vlastne mel na mysli ?

[scoufal]

Některé DB materialized views mají. MySQL a MariaDB ne. VIEW z MariaDB nemá cenu, ta se provádí vždy znovu.

V MariaDB se používají triggery, aspoň podle ChatGPT