ortsuev33, имеет) вам же надо как-то получить признак, успешности или не успешности вашего сценария, чтобы сделать либо commit либо rollback. В идеале нужно проверять каждый узел (запрос), возможно даже с отловом исключений через try...catch
встречный вопрос: какой аргумент в сторону использования массивов перед словарем?
Легкость выборки, со словарем, как я понимаю в том, что мы можем достать пользователя только по ключу, соответственно словарь должен быть либо map[int]*Client если по айдишнику или map[string]*Client если по юзернейму. И если выборка осуществляется только по этому идентификатору то все удобно, конечно. Но если будет нужна выборка по нескольким полям (не одновременно) или же по вложенным структурам, напр. по айпишнику или по другому критерию, то удобнее использовать слайс. Почему мы не можем итерироваться по карте так же как по слайсу? Потому что слайс производительней работает в циклах, а карта же быстрее работает для поиска элемента. Поэтому для меня тут + слайса очевидны. Ну и при использовании цикла со слайсами мы получаем обычный алгоритм линейной сложности, только для любого поля структуры.
Даша Циклаури, Такс, hash индексы используются для одиночных выборок, tree индексы используются для range выборок. Исходя из задачи, раз тут 1х1, я считаю что выгоднее будет иметь хэш таблицу (обычный массив/слайс) и в цикле просто сравнивать нужное поле (client.id, client.username) и на основе этого забирать клиента. Не вижу тут профита в разведении деревьев. Хэш индексы используются в бд и на миллионах записей, или они там как-то по другому работают или я не в ту сторону думаю?
Даша Циклаури, хочу просто понять вашу точку зрения. Вы предлагаете использовать tree индексы для поиска подключенных клиентов? Т.е. будет массив/слайс с клиентами и будут несколько tree индексов для каждого поля клиента и ссылаться они будут на самого клиента? По поводу константы это вы имеете в виду доступ по ключу словаря? Как по мне дак мьютексы хороши там, где они хорошо делают свою работу и где не нужна излишняя сложность с каналами. https://dave.cheney.net/2016/11/13/do-not-fear-fir... не коннектит
Даша Циклаури, я считаю что мьютексы надо использовать в самых простейших случаях. А не городить везде каналы. Мое субъективное мнение. Tree индексы это уже ближе к субд. Под выборкой я имел в виду получателя. Чтобы можно было выбрать не только по никнейму но и по айди например. И получается простая "хэш таблица" с линейной сложностью. То есть с 1 пробегом по массиву. Так же использование rwmutex дает улучшенную производительность чтения. Вот интересная статья по этому поводу: https://m.habr.com/post/271789/
Даша Циклаури, конкретно в этом случае - возможно. Однако все равно дальше придется усложнять структуру Clients и туда могут добавиться другие идентифицирующие поля. И все равно придется циклом бегать и навешивать рвмьютексы
Влад, либо нормализировать данные перед парсингом, чтобы не было переводов строк между данными, либо использовать например первый ключ как разделитель, как вариант _wpcf7, вместо перевода строки
slo_nik, :DDD ну это уже серьезно. Я свое мнение высказал, надеюсь придут еще люди которые понимают хоть что-то в юи валидаторах и вам объяснят)) ну или мне, вдруг я ошибаюсь х)
slo_nik, это сообщение(message) относится только к ВАЛИДАТОРУ. Я еще раз повторю, when не валидирует, она указывает когда мы применяем валидатор, а когда нет. В зависимости от того что отдаст функция или ключ. По дефолту все валидаторы включены. Ваша проверка не имеет смысл, вы 2 раза используете date валидатор, только во втором случае он будет применяться при определенных условиях.
slo_nik, я про date_to, он останется неотвалидирован в случае false из анонимной функции, так как параметр when не валидирует, он говорит процессу валидации, что вот этот валидатор мы запускаем, а этот нет, это не сам валидатор, а date_to будет safe потому что когда мы вызываем функцию load она смотрит для каких полей у нас есть валидаторы, и их помечает как safe и загружает в них данные, хотя по факту валидация может не пройти, если when = false
