просто интересно Програмёр
ты писал когда-нибудь распределённые системы?!
сидят два оператора с твоей таблицей в 65к ячеек и потихоньку вносят изменения...
как вариант - один удалил строку а второй пытается внести туда изменения...
или один обновил данные, а второй, невидя этого, перезаписал туда старые данные...

предложи вариант решения? ;)
авторно и это за денёк думаю можно освоить в полной мере...
добрый совет ;)

не актуально в рамках данного топика по сути )) тут вот какое дело, если один оператор удалил поставку, то другой уж точно её править не будет ))) Это не логично и говорит об нарушении организации :) Ну, это моё мнение...

А вообще должна быть кнопочка "обновить", которая позволит загрузить все новые правки с сервера... Если я стараюсь записать строку, которой уже нету - я должен получить сообщение об ошибке... Что бы избежать жуткого переплетания работы (не знаю, мне так удобнее по крайней мере, да и прогать легче, ещё никто не жаловался), можно все изменения в базе писать единной транзакцией.. То есть, внизу сделать кнопочку "сохранить изменения на сервере"... пока мы меняем данные (добавляем/удаляем ячейки, меняем тексты) все запросы (в виде логированных изменений) скапливаются где-то... а когда жмём кнопочку - данные действия переводятся в запросы и выполняются (отправляются в базу)... если какой-то запрос заканчивается ошибкой - пользователю можно предложить например отказаться от изменения данных (которые не могут быть изменены), или предпринять другие действия (например добавить (в данном случае вернуть) отсутствующий столбец, строку или таблицу)... Кстати, перед записью надо повторно валидировать данные :) ведь они могут измениться (то есть кто-то мог изменить тип столбца)... И при провале валидации предлагать пользователю поправить значения этих полей.

А какой Вы предложите вариант решения? (мало ли, может я и не прав... если так, то поясните)

просто интересно http://dr-magic.blogspot.com/2010/01/3.html - шеф всё уже давно украдено до нас!
автор если какой-то запрос заканчивается ошибкой - пользователю можно предложить например отказаться от изменения данных (которые не могут быть изменены)
О как! То есть сервер сам толкнёт клиента?

Вы меня видимо не поняли... зачем сервер толкнёт клиента (в принципе я даже не знаю как, ведь на то он сервер, что бы его клиенты толкали)... А предложить клиенту отказаться от изменений по нажатию кнопки "сохранить изменения в базе". То есть, он нажал, сервер начал обработку... в случае возникновения ошибок, запомнил их... сверил с действиями, повлекшими ошибки и обработал причину ошибок, на основании этого отправляет клиенту возможные варианты решения проблемы... js это выводит клиенту, тот предпринимает одно из предложенных действия и даёт "перезапрос"... сервер снова его выполняет... если появляются ошибки, снова спрашивает как поступить с несохранёнными данными... и так пока не сохранит данные :)

просто интересноавторRecordset
!!! так вот этот самый Recordset тебе придётся самостоятельно реализовать для решения подобного рода коллизий ;)
если вдруг подобное решение тебе покажется громоздким или оч сложным, тебе придёт в голову, что править строку можно не напрямую в общей таблице с данными, а выбрав её последнюю версию непосредственно запросом на страницу правки записи!!!
и залочить ОДНУ единственную строку от других! а не все строки таблицы!

Програмёр
ОМГ! теория обновления данных по ЭНТЕР при изменении в отдельно взятом инпуте, вероятно разрушилась?
как и теория перехода по ячейкам таблицы с кучей инпутов стрелочками! Следущая на очереди - <span> в каждом диве или ячейке таблицы? ;)
хорошо! как в таблицу из 65к ячеек получить изменённые др пользователем данные?
авторкнопочка "обновить"
? ;) как часто её будет нужно нажимать?

Ваш вариант так и не был озвучен :) Если Вы решили подержать его на последок - уже начинаете передерживать... Начинает складываться впечатление что его или нету, или он уступает одному из озвученных... Расскажите, как бы Вы это решали.

По поводу Энтер - ничего не разрушилось, я всего лишь предложил альтернативу, которая позволила бы так часто не пересекать работу двух операторов... Один сохранил изменения, второй после него попробовал сохранить конфликтирующие данные, запрос отвалился... первый продолжает что-то менять... снова сохранил... всё ок... второй всё исправил, сохранил... первый попробовал сохранить, у него конфликт... исправил, сохранил... А теперь представляете, если несколько операторов одновременно и у них каждое второе поле в конфликте?.. Это как в гитхабе... Вы работаете в своей ветке... когда работу закончили - слили в мастер, если наткнулись на конфликт - решили и закомитили результирующий вариант... А теперь представляете, если бы Вам пришлось решать конфликты по каждому коммиту? ... а теперь представляете, если Вы конфликт решили, а на сервере уже новый коммит появился... и Вы снова конфликт решаете... так его можно решать 2 месяца )) будете не рады такой системе и быстренько с неё спрыгните.

Итак, ждём Ваш вариант :) просветляйте нас пожалуйста...

То есть сформулировать мою идею можно так:
я предложил избавиться от процесса прямой записи в базу и просто "сливать" изменения на основной сервер... как в гите... только вместо своей ветки, Вы создаёте временную таблицу (виртуально... просто в сессию нотируете свои изменения)... когда Вы решаете, что всё готово - вливаете в основную таблицу свои правки, если возникают конфликты, процесс вливания отменяется, Вам предлогается решить конфликт, после чего Вы можете повторить вливание...

Вроде всё просто, а принцип уже давно изучен и уже используется очень удачно :)

Сергей ЛаловBagaBaga,
Давайте не будем передергивать))) топикстартер просто переползает с десктопа на веб. И опыт в практическом программировании в сумме зачастую перекрывает срок, с которого у некоторых участников данного форума начались проявляться вторичные половые признаки.

Хм... :) А в чём Вы видите проблему такого перехода? :) Проблемы обычно бывают при переходе в обратную сторону... Ну разве только привыкнуть к структуре клиент-сервер, но в принципе, любое приложение работающее с основным ресурсом в сети работает по такому принципу... разница лишь в том, что браузер не удерживает соединение после окончания загрузки страницы (то есть по сути связь односторонняя, а для двусторонней уже приходится играться) :) Не знаю... это как создание gui под уже давно написанное консольное приложение )) Только приложение - это серверная часть, а gui - клинтская (js, html, css). Если у Вас огромный опыт разработки, Вам это должно быть как 2 пальца.... ;)

просто интересноавторПредлагаете топикстартеру освоить какой-нибудь Message_Queuing? Или пилить самому - ради опыта :) ?
хотел ему подкинуть идею о том, что если бы так легко переносились десктоп приложения с их контролами на веб, то, вероятнее всего, кто-то уже придумал бы необходимый ему (похожий на MS Access) грид! хотя, конечно может и запилить! ;)
авторИтак, ждём Ваш вариант :)
http://wiki.apache.org/couchdb/HTTP_Document_API почитай - зачем нужны "_revisions" ;)
авторВроде всё просто, а принцип уже давно изучен и уже используется очень удачно :)
уверен, что не тобою! это называется Recordset в десктопе! в веб всё это можно организовать даже на клиенте http://htmlbook.ru/html5/storage
Вопрос один - ЗАЧЕМ? ради того что бы затянуть на клиента 40к строк из таблицы БД и вкорячить в супер-грид???


Ну так Вы просто прокоментили мой вариант, что да, это есть и это можно запилить... Но я ведь это и говорил... о чём Вы тогда спорили? :)

По поводу запилить логику на клиенте - интересно... а как клиент будет с сервера получать инфу о том, что были измененены определённые поля?... Вообщем, возможно конечно так можно сделать (думаю не без гемора), но я бы не стал... Пояснение в прошлом сообщении (сервер - логика, клиент - интерфейс)...

А я и не предлагал 40к строк тянуть... Фильтры для того и обсуждались, что бы не тянуть лишнего... и именно по той причине я и советовал фильтровать всё на уровне базы (и сортировать тоже)... То есть если нам нужна выборка из трёх полей, по значению одного из полей и отсортировано в порядке возрастания второго из полей, так мы в итоге именно это и дёрним из базы... и получится например 200 строк из трёх столбцов по возрастанию второго поля :)

Так о чём же Вы спорили, когда говорили, что фигня это всё (когда угнетали мой вариант )?

просто интересноавторТак о чём же Вы спорили, когда говорили, что фигня это всё (когда угнетали мой вариант )?
какой вариант?! сохранить все сделанные пользователем изменения и одним махом отправить их в БД?
обрыв соединения?! три часа внесения изменений насмарку! неа ;)
авторА я и не предлагал 40к строк тянуть...
14755439 - за тебя предложили...

мне трудно с тобою разговаривать - ты всё это как-то нащупываешь\придумываешь, вместо того, что бы сесть и попробывать сделать!

Ну так я же предлагаю разные варианты, которые понятное дело могут иметь свои минусы, которые сам и описываю... Пожалуйста, хотите что бы при обрыве данные об изменениях не терялись - пишите не в сессию, а во временную таблицу :) Это не суть важно... об обрыве соединения как таковом не задумывался, так как обойти несложно....

Однако, по Вашим словам есть какой-то механизм, который позволяет избавиться от всех возможных минусов (такой себе идеал), однако Вы его не рассказываете... Что же мы тогда обсуждаем... То есть сейчас ощущение, что Вы не помочь стараетесь, а просто бракуете то, что я предлагаю, вместо того, что бы потритить 10 минут и написать сюда метод решения, который я и сам возможно признаю лучше своих и буду пользовать в будущем... Но пока ничего не написали, лучшие варианты решения вопроса остаются мои (пока они единственные, так что в любом случае лучшие )

Сергей Лалов, учитывая что Вы решили использовать готовые фреймворки для решения задачи, вопрос снимается? ))

просто интересно Програмёр
мне просто интересно было посмотреть - делал ли ты в реальной жизни нечто подобное - исходя из того, что для тебя это "часик подумать"... оказалось - НЕТ!!! ничего подобного ты не делал, тк. придумываешь на ходу и думаешь уже не один час!
авторкоторый позволяет избавиться от всех возможных минусов
от всех возможных минусов избавиться помогает один способ - не притрагиваться к клавиатуре... ;)
1. на клиента тянется минимальное кол-во строк
2. эдит строки с нового запроса
3. _revisions

Karbafos
вот ты и подумай!!! http://en.wikipedia.org/wiki/Push_technology

Ой, ладно не делал... Делал... revisions не использовал (сорри, читать лень :) там много, дак ещё и по-английски, приходится напрягаться)... По поводу push технологии - делал. Захватывал соединение сервером, так делал на сайте, который сейчас разрабатываю. Использовал в модуле работы с письмами... То есть, мне нужен был моментальный отклик с сервера о том, что кто-то отправил письмо, что бы 2 оператора не отправили одному и тому же человеку письма с одинаковым содержанием :)... Но, как я говорил, это неправильная структура работы. Потом мы доработали на сайте систему очереди обработки заказов и от захвата соединения сервером отказались (как ни как, а держать 20-30 открытых постоянно соединений - это не круть). Ведь теперь у нас работа операторов не пересекается... То есть, если один оператор работает с заказом, то другому этот заказ не покажится как приоритетный... А значит другой оператор не возьмёт заказ на обработку.

Насчёт думаю больше часа ))... Не думаю... Я на каждое письмо отвечаю сразу после прочтения, без раздумий... Вы мне указываете на проблему - я сразу пишу ответ как её избежать... Так что в общей сложности я думал минут наверное.... 10 :)

KarbafosПрограмёрПожалуйста, хотите что бы при обрыве данные об изменениях не терялись - пишите не в сессию, а во временную таблицу :) Это не суть важно... об обрыве соединения как таковом не задумывался, так как обойти несложно....

обрыв соединения с БД в бэкенде, во временную не записалось =)

блин, для веба сходу можно придумать минимум 3 варианта, как не допустить коллизий. разной степени замороченности, но так или иначе решающих проблему.

просто интересно

а по поводу сервер сам пнет, если надо будет, то пнет клиента в ответ на его запрос =) каким образом, сам думай.

Обрыв соединения во время работы с БД... данные не сохранились... какая разница? ))) То есть, Вам будет легче, если они не сохранятся в основную таблицу, чем если они же не сохранятся во временную? Не понимаю фишки ))

просто интересноавтор(как ни как, а держать 20-30 открытых постоянно соединений - это не круть)
а прыгать в гриде по 100к ячеек, вызывая при этом запрос сервера на версионность ячейки в текущий момент и, при нажатии ЭНТЕР посылать запрос на обновление данных - это круть!!!
авторОбрыв соединения во время работы с БД... данные не сохранились... какая разница? ))) То есть, Вам будет легче, если они не сохранятся в основную таблицу, чем если они же не сохранятся во временную? Не понимаю фишки ))
фишка в обновлении одной единственной строки (которая не обновилась при разрыве)! и обновлении большой таблицы данных, над исправлениями в которой ты потратил 3 часа!!!

ты как из ДС - кнопочка "обновить"!!! вроде что-то делал, а элементарных вещей незнаешь или "не задумывался"



1. Я не говорил, что при переходе между ячейками надо запрашивать версионность... А если даже и нужно было, удерживание соединения сервером - это то же самое... Сервер может ответить только единожды, после чего соединение закрывается (как помним в целях безопасности мы не можем создавать keep-alive соединения). Потому перезапрос будет происходить даже при push запросах.

2. На то и делаются транзакции )) При обрыве соединения мы получим ошибку, а изменения применены не будут никакие, после возобновления связи мы делаем перезапрос на запись и вносим все изменения одним разом.... Намного хуже, если мы в базу сохранили 100 полей, а сто первое не сохранилось... Потом оператор, который обрабатывает заказ дальше, не знает, что последняя позиция обновлена не была, и обрабатывает её старое значение... в итоге косяк. Так лучше думаете?

3. За ссылки спасибо, чуть позже почитаю... Уехать надо )) Завтра утром постараюсь прокоментировать то, что вычитаю :)