Здравствуйте, хотел узнать по поводу настроек Insert, Update, Save и загрузки данных из БД прямо в таблицу (DataTable).
Использую node.js и не совсем понимаю как отправить сразу данные через скрипты в таблицу, т.к в данный момент отправлял на сторону клиента с сервера.
Так же вопрос, возможно ли сделать обновление таблицы в реальном времени, что если ею пользуется несколько человек и кто-то что-то изменил, оно изменилось у всех?
Я начал делать сам с вебсокетами, но проблема такая, что отличается ИД строк, т.е на первой странице например ИД: 1638267532625 это site.com, а на обновляемой странице другого окна, под этим идом например site2.com, а должен быть по идее site.com и встает вопрос, как обновить тогда данные нужной мне строки?
вообще странная ситуация. по идее в сообщении должна быть айдишка из базы, с ней же объект добавляется на второй клиент. на первом клиенте временная айдишка тоже заменяется на серверную. сужу по коду примера:
this.socket.onmessage = (e) => {
const update = webix.DataDriver.json.toObject(e.data);
if (update.key != this.key) return;
// 1st client - issues changes
if (update.clientId == this.clientId){
if (update.operation == "insert")
view.data.changeId(update.id, update.data.id);
} else { // 2nd client - receives changes
webix.dp(view).ignore(() => {
if (update.operation == "delete") {
if (view.exists(update.data.id)) view.remove(update.data.id);
} else if (update.operation == "insert") {
view.add(update.data);
} else if (update.operation == "update"){
if (view.exists(update.data.id)) view.updateItem(update.data.id, update.data);
}
});
}
};
Что-то я не совсем понимаю когда это происходит, и не совсем понимаю логику по статье.
В какой-то момент и как присваивается ИД на сервере, для чего нужен сам webix proxy и как подставляется серверный ИД на клиенте.
Каким образом можно присвоить строке ID? Думаю решение этого вопроса, даст ответ на все вопросы выше, т.к смогу сам всё остальное написать думаю, а может и нет, учитывая что я пока не совсем понимаю для чего нужен Proxy.
Подмена айдишки с клиентской на серверную происходит после того, как запись была добавлена в ДБ и на клиент пришло сообщение об этом (this.socket.onmessage с операцией insert). Делается это методом changeId (см код выше). Просто присвоить объекту типа obj.id = update.data.id не получится. Айди поле непростое.
Статья рассказывает о том, как поэтапно создавался наш пример с прокси, который работает с сокетами и обеспечивает взаимодействие клиентской части и бэкенда. Может у вас есть какие-то вопросы по моментам в статье? На общие вопросы отвечать сложновато
Прокси (вне зависимости от того, чем конкретно они занимаются) нужны как прослойка между клиентом и бэкендом, когда клиент сам по себе не делает то, чего от него ожидает бэкенд. То есть он подготавливает данные перед отправкой на бэкенд и/или подготавливает данные с бэкенда перед тем, как они появятся в клиентских данных.
Конкретно этот прокси стартует веб-сокетовое соединение и добавляет код для обработки ошибок и сообщений с сервера (тот самый onmessage).
На сервере айди присваивается при инсерте новой записи в таблицу, например id primary key - просто инкрементирует айди последней записи и присваивает новой. В этом примере бэкенд имитируется, и там вручную айди делается.
Вообще можно и как-то по-своему реализовать и сокеты, и коммуникацию между клиентом и бэкендом с сокетами. Прокси - готовое решение, адаптированное под работу с url/save пропертями и встроенной логикой вебикса.
Просто я реализовал соединение и передачу клиентам данных с клиента на сервер и обратно и единственная загвоздка у меня именно с ID строки. Так как у одного клиента она одна, а у другого другая, вплоть до того, что такого индекса может не быть и я не понимаю именно в какой момент на клиенте нужно устанавливать ID строке, особенно если у меня данные в таблицу заполняются через JSON переменную.
Обработайте onmessage и там подмените, если это тот же клиент, что добавил запись и отправил на бэкенд. (тут в примере для идентификации клиента используется айди, которая передается при установке соединения, может у вас что-то такое же есть)
Я хочу заменить у других, кто так же подключен к сайту в данный момент.
При замене каких-либо данных, я отправляю строку на сервер, там делаю определенные операции и возвращаю другим клиентам, но т.к ИД строки у них другой, то и записывать данные нет туда смысла, т.к они заменят совсем не то что нужно, а может и вообще не быть такой строки.
Единственное что пока получается, это обновление таблицы при перезагрузке страницы, но это не тот вариант который нужен, а как установить ид строкам или пройти по строкам таблицы я не понимаю, как вообще обратится к какой либо строке не зная её ид? Есть ли массив данных у таблицы к которому можно было бы обратится не зная ид?
При замене каких-либо данных, я отправляю строку на сервер, там делаю определенные операции и возвращаю другим клиентам, но т.к ИД строки у них другой, то и записывать
вот этот момент не очень понятный. почему у разных клиентов ID строки разный?
изначально все клиенты получают одинаковые ID из базы
если какой либо из клиентов создает новую строку, то все клиенты получают пакет { operation:insert } который содержит ID новой строки как оно сохранилось в базе, так что оно опять будет одинаковое у все ( клиент создатель обновляет ID через changeID вызов, остальные клиенты добавляют новую строку сразу с правильным серверным ID )
Ключевая идея в том что клиент на котором создаются новые данные не рассылает их всем остальным, а шлет на сервер, где данные сохраняются в базу, им присваиевается серверный ID и запись уже с этим ID рассылается всем, в том числе и оригинальному клиенту, чтобы он поменял временное ID на серверное
все другие клиенты получают ID из базы, после того как строка сохранится
Вопрос, одинаковый ID строк из базы или что именно?
Потому что я когда отправлял данные с клиента на сервер и другому клиенту, под идом строки, находилась либо другая строка, либо её могло и не быть вовсе.
у одной и той же записи на бэкенде и на всех клиентах должна быть одна и та же айди. если айди разные - считается, что это разные записи.
вопрос в том, как получилась такая ситуация, что на клиентах и на бэкенде в базе данные в принципе разные? все клиенты, по идее, должны грузить данные из базы. дальше клиенты отправляют свои обновления на бэкенд, а он уже рассылает сообщения в ответ (и все клиенты на них реагируют как-то - или обновляют в своих данных айди, или добавляют новые данные - это для операции insert)
один клиент другим ничего не должен отправлять (данные с клиента на сервер и другому клиенту - другому клиенту не надо)
данные в клиент как-то попадают по-другому? у каждого какие-то свои, а на бэкенде в базе еще какие-то? это странная ситуация, если так.
ну я делал отправление данных и загрузку в ручную, т.е я отправляю на клиент json переменную, и уже на клиенте сетаю ее в таблице, а при изменениях в таблице, отправляю на сервер и сохраняю в БД и отправляю на клиент, но т.к ИД строк разные, то ничего не могу заменить.
Я так понимаю можно как то через REST сделать загрузку и обновление без передачи переменных на клиент?
То есть, если я правильно понимаю, это просто как обмен JSON данными и сохраняли вы данные не через наш save, а как-то сами? по каким-то событиям, по onStoreUpdated, например?
А сервер выставляет случайные айдишки? Если да, то в таком случае действительно нереально обработать ответ по какой-то записи или обновить все данные через parse, не очищая всё перед этим.
Я думаю, было бы здорово, если бы вы могли показать ваш код. Тот, который грузит данные, отправляет данные на бэкенд, принимает их с бэкенда.
Как вариант это обновлять всю таблицу на клиенте и выбирать последнею выбранную строку, но я так и не понял как выбрать строку, например на последней странице таблицы. Либо метод не работает с пагинацией, либо я что-то не так делал.
Если бы я точно видела, что с клиента уходит на бэкенд и чем бэкенд отвечает, мб что-то могла бы сказать, а так - тоже не понимаю, к сожалению.
А какой метод и как именно вы это делали?
После ресета всех данных таблица уже не хранит селект, состояние нужно перед ресетом где-то сохранить, чтобы потом применить опять.