АГ
в точку) хмл это безысходность) кстати, а в чем задача то? кодогенерация моделей или валидация хмл? и то и то - вполне себе серьезные задачи, и для решения архитектуру надо продумывать какую никакую
Size: a a a
2020 November 15
NF
в точку) хмл это безысходность) кстати, а в чем задача то? кодогенерация моделей или валидация хмл? и то и то - вполне себе серьезные задачи, и для решения архитектуру надо продумывать какую никакую
думаю ему для собственных нужд хватит статики на js или даже консольного приложения)
NF
Просто $.xml2json(xml) потом из этого файла создать ag-grid строчек в 100, потом загрузить в него данные с fetch и парой контролов. И BI инструмент готов к использованию. @proffi01 вдруг это то что тебе нужно, часика за 4 можно сделать супер удобно.
ИП
Поищи готовый, возможно кто-то уже использовал это до тебя. А вообще в XSD умеет любой XML парсер. Загружаешь в него XSD схему, он возвращает модель. Ну вообщем по документации не сложно понять как это использовать и для чего.
Больше спасибо!
2020 November 16
˸A
это из книги Алана Купера - Психбльница в руках пациентов, начал читать, оч годная
Интересная книга. Тоже начал читать. Спасибо
m
Интересная книга. Тоже начал читать. Спасибо
больная тема: на чем читаешь?
DE
С быстрыми вольюмами :)
˸A
больная тема: на чем читаешь?
На телефоне. Fb2 формат скачал
NI
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
k
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
это 10 000 юзеров на 1 параграф?
NI
это 10 000 юзеров на 1 параграф?
Нет, одновременно с системой работают 10 000 пользователей. Один параграф в среднем будет просмотрен 3 людьми для утверждения, т.к. нужно либо два valid, либо два invalid
N
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
выглядит как учебный кейс, а не как случай из практики
YG
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
А книга это и есть документ?
NI
А книга это и есть документ?
Да. Одно и то же
EK
я конечно не эксперт
но в лоб просится сделать отдельные очередя для непровалидированных книг
соответственно когда юзер хочет что то валидировать можно узнать что он валидировал раньше и обращаться в те очереди где лежат невалидированные параграфы
но в лоб просится сделать отдельные очередя для непровалидированных книг
соответственно когда юзер хочет что то валидировать можно узнать что он валидировал раньше и обращаться в те очереди где лежат невалидированные параграфы
N
выглядит как учебный кейс, а не как случай из практики
Решение: непройденные параграфы отсортированы внутри книги, непройденные книги отсортированы внутри системы. У юзера есть счетчик с номером книги, параграф из которой он получит следующим. При каждом получении параграфа он инкрементируется. В книге есть счетчик с параграфами. При каждой выдаче параграфа он инкрементируется до следующего не до конца обработанного параграфа.
В итоге есть аггрегат юзера и агрегат книги, каждого из них можно дернуть по "дай следующий". Блокировок нету.
В итоге есть аггрегат юзера и агрегат книги, каждого из них можно дернуть по "дай следующий". Блокировок нету.
NI
Решение: непройденные параграфы отсортированы внутри книги, непройденные книги отсортированы внутри системы. У юзера есть счетчик с номером книги, параграф из которой он получит следующим. При каждом получении параграфа он инкрементируется. В книге есть счетчик с параграфами. При каждой выдаче параграфа он инкрементируется до следующего не до конца обработанного параграфа.
В итоге есть аггрегат юзера и агрегат книги, каждого из них можно дернуть по "дай следующий". Блокировок нету.
В итоге есть аггрегат юзера и агрегат книги, каждого из них можно дернуть по "дай следующий". Блокировок нету.
Хм, предположим ещё не было никаких активностей и прилетает 100 запросов от 100 пользователей. У всех счётчик книг = 0, соответсвенно все обратятся к одной книге. Хотя, может, я неправильно понял ваш вариант решения
N
Nikita Ilin
Хм, предположим ещё не было никаких активностей и прилетает 100 запросов от 100 пользователей. У всех счётчик книг = 0, соответсвенно все обратятся к одной книге. Хотя, может, я неправильно понял ваш вариант решения
все обратятся к одной книге и получат 100 последовательных параграфов из нее
NI
Так а счётчик книги не надо обновить сто раз?