Здравствуйте, gandjustas, Вы писали:
G>Плохому танцору... ну ты понял.
Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
BDA>>Короче, я шарик раньше сам продавал кому хочешь, мне его продавать не надо. Я скорее на брейнфаке буду программировать СУБД под свою задачу, чем соглашусь еще раз коснуться этого отстоя. G>Так тебе всетаки шашечки, а ехать и не нужно? Или ты думаешь, что запилив свою метамодель на СУБД с версионностью каждой строки у тебя прямо офигенский результат получится и язык запросов не жуже SQL? И сколько ты собрался это делать? Год? Два?
Зачем мне свой язык запросов? Я что, Майкрософт, с ее поиском фатальных недостатков? Если бы ШП давал SQL-интерфейс к [AllUserData], включая документацию, я бы, МОЖЕТ БЫТЬ, закрыл глаза на его общую упячность. А совсем без программирования у них тоже не получится — возьмем, например, такую ма-а-а-аленькую проблемку, как отказ считать результат агрегирующих функций (то, что во вьюхах идет как Total или типа того, не помню) гражданами первого класса, то есть элементами списков. Все-таки, dogfooding'а у них не было, это говорит каждый, кто пробовал запилить на шаре хотя бы элементарный багтрекер.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Теперь, что касается клиента. Уметь представлять таблицы надо по заданным шаблонам, например, поля булевого типа надо показывать как обычным чекбоксом, так и супегламурным айфоноподобным анимированным. И желательно, чтобы сервер об этом ничего не знал. То есть, много кастомных контролов и CSS. Наваять на обычном jQuery + UI? Или взять что-нибудь вроде Angular?
у меня нет опыта веб-программирования, но чисто по рекламе мне очень понравился webix
Здравствуйте, 0BD11A0D, Вы писали:
BDA>2) ломать голову об 100500 конфигов, поэтому Java нежелательна.
100500 конфигов это миф, который к современной Java не имеет никакого отношения.
Для прототипа можете выбрать связку Spring Boot + PostgreSQL + Heroku
Конфиги не требуются, нужно только выбрать фичи, которые хотите иметь в своем приложении: http://docs.spring.io/spring-boot/docs/current/reference/html/getting-started-first-application.html
Здравствуйте, gandjustas, Вы писали:
BDA>>Он не является фреймворком, и этого достаточно. Но, между нами, он еще и редкое УГ.
G>А вам шашечки или ехать? Все что описано — умеет изкаропки, а что еще для прототипа надо?
Я же сказал, он не является фреймворком. Сделать с ним ничего непредусмотренного неизвестными индусами нельзя, развивать в нужном направлении нельзя, можно только поставить и наслаждаться «искаропочностью». Недолго, правда. Последний раз, когда я его смотрел, банальнейший апдейт одного списка на несколько тысяч элементов по сложному условию сделать было невозможно. Ибо CAML не поддерживал(-ет?) сложные условия, космически уступая даже SQL, и приходилось крутить его в цикле, минимум по 2 запроса на элемент. При этом встроенный недокументированный таймаут на 30 секунд (? — точно не помню уже) тупо выгружал dll'ку, оставляя виртуальную базу в неконсистентном состоянии. А, как начал писать, всю говенность его вспомнил — и милая архитектура «1 событие — 1 класс (не инстанс! класс!)» заставляет генерировать простыни Handler1, Handler2 ... Handler3. Работать в результате можно только на живой базе, но там есть свои приколы. Полное отсутствие документации, например.
Короче, я шарик раньше сам продавал кому хочешь, мне его продавать не надо. Я скорее на брейнфаке буду программировать СУБД под свою задачу, чем соглашусь еще раз коснуться этого отстоя.
P.S. И на всякий случай: установить ШП не значит создать прототип чего бы то ни было, кроме как инсталляции ШП. Которая у меня, к слову, и так имеется.
Есть схема БД, которая определяется юзером. Сама юзерская БД примитивная (всего несколько типов колонок), но все же БД. Ее нужно замапить на сервере на какой-нибудь мускул. Проблема в том, что стираться ничего не должно (бесконечной глубины Undo). Отсюда следует, что простейшее решение — создавать/менять/убивать таблицы в настоящей БД один в один с виртуальной юзерской — немного не катит (?), нужны метаданные.
В продакшене по мере нагрузки можно будет переписать все на ++/noSQL, а для прототипа нужно что-нибудь, чтоб попроще был код и мало его.
Что посоветуете? Да, очень не хочется даже в прототипе: 1) тащить зависимости от виндов, поэтому .Net нежелателен; 2) ломать голову об 100500 конфигов, поэтому Java нежелательна. Но, конечно, если есть суперудобные решения для этих платформ, я готов мириться.
Теперь, что касается клиента. Уметь представлять таблицы надо по заданным шаблонам, например, поля булевого типа надо показывать как обычным чекбоксом, так и супегламурным айфоноподобным анимированным. И желательно, чтобы сервер об этом ничего не знал. То есть, много кастомных контролов и CSS. Наваять на обычном jQuery + UI? Или взять что-нибудь вроде Angular?
Здравствуйте, xednay89, Вы писали:
BDA>>Есть схема БД...
X>Не совсем понял что надо, но если взять postgreSQL с json-ами, которые он поддерживает — это не поможет?
Не поможет, или я не понял, как использовать.
Что надо — надо дать пользователю виртуальную БД, а данные этой БД где-то хранить. Для начала, в реальной SQL-базе. Причем, что важно, юзерские запросы не тупо транслировать в БД, а хранить в виде записей: юзер создал таблицу, юзер добавил колонку, юзер внес запись, юзер убил таблицу. Чтобы можно было откатиться на любую дату, а данные никогда нельзя было потерять.
Надо полагать, ORM для этого не очень подходит.
Re[3]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, xednay89, Вы писали:
BDA>>>Есть схема БД...
X>>Не совсем понял что надо, но если взять postgreSQL с json-ами, которые он поддерживает — это не поможет?
BDA>Не поможет, или я не понял, как использовать.
BDA>Что надо — надо дать пользователю виртуальную БД, а данные этой БД где-то хранить. Для начала, в реальной SQL-базе. Причем, что важно, юзерские запросы не тупо транслировать в БД, а хранить в виде записей: юзер создал таблицу, юзер добавил колонку, юзер внес запись, юзер убил таблицу. Чтобы можно было откатиться на любую дату, а данные никогда нельзя было потерять.
BDA>Надо полагать, ORM для этого не очень подходит.
То есть некое подобие лога транзакций? — может в эту сторону покопать..?
Re[4]: Какие фреймворки использовать для прототипа?
Здравствуйте, iPrior, Вы писали:
BDA>>Что надо — надо дать пользователю виртуальную БД, а данные этой БД где-то хранить. Для начала, в реальной SQL-базе. Причем, что важно, юзерские запросы не тупо транслировать в БД, а хранить в виде записей: юзер создал таблицу, юзер добавил колонку, юзер внес запись, юзер убил таблицу. Чтобы можно было откатиться на любую дату, а данные никогда нельзя было потерять.
BDA>>Надо полагать, ORM для этого не очень подходит.
P>То есть некое подобие лога транзакций? — может в эту сторону покопать..?
Мне кажется, нет. Данные об операциях должны быть гражданами первого класса, а записи в transaction log — какие-то системные, судя по тому, что я прочитал. Впрочем, если на них удастся построить хак, я только за, но как, например, в мускуле запросить данные из таблицы, дропнутой полгода назад? Можно его так настроить?
Re[5]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
P>>То есть некое подобие лога транзакций? — может в эту сторону покопать..?
BDA>Мне кажется, нет. Данные об операциях должны быть гражданами первого класса, а записи в transaction log — какие-то системные, судя по тому, что я прочитал. Впрочем, если на них удастся построить хак, я только за, но как, например, в мускуле запросить данные из таблицы, дропнутой полгода назад? Можно его так настроить?
я не думаю что получится использовать лог транзакций, но логику можно взять на вооружение.
Грубо говоря, хранить все запросы к базе данных, прям в SQL виде.
Если нужно откатиться до какого то времени, то можно просто выполнить все запросы по очереди до этого времени, на новой схеме.
Ну это так, на вскидку...
Так или иначе всё сведется к журналу операций.
Другой вопрос сколько он будет весить через неделю, месяц, год... и как реализовывать механизм "отката".
Готовых решений я не встречал, собсно как и с такой задачей.
Re[2]: Какие фреймворки использовать для прототипа?
Если это миф, то почему по вашей же ссылке лежит конфиг? Я не хочу раздувать холивор, но про Джаву я давно знаю, что это способ нагнать важности девелопменту и раскрутить заказчика на бабки. А у меня цель противоположная — прототип написать как можно быстрее и дешевле. И если только не окажется, что в Спринг встроена поддержка виртуальных баз, нахрен мне это счастье — ПОМы, Мавены и прочее. Надо у жены спросить, она с этим Спрингом хорошо знакома.
Re[3]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, xednay89, Вы писали:
BDA>>>Есть схема БД...
X>>Не совсем понял что надо, но если взять postgreSQL с json-ами, которые он поддерживает — это не поможет?
BDA>Не поможет, или я не понял, как использовать.
BDA>Что надо — надо дать пользователю виртуальную БД, а данные этой БД где-то хранить. Для начала, в реальной SQL-базе.
Пусть так и будет.
BDA> Причем, что важно, юзерские запросы не тупо транслировать в БД, а хранить в виде записей: юзер создал таблицу, юзер добавил колонку, юзер внес запись, юзер убил таблицу. Чтобы можно было откатиться на любую дату, а данные никогда нельзя было потерять.
Это можно решить используя паттерн undo/redo stack, только хранить все запросы в бд.
BDA>Надо полагать, ORM для этого не очень подходит.
Скорей всего да и в первую очередь из-за скорости.
Программа – это мысли спрессованные в код
Re[3]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Если это миф, то почему по вашей же ссылке лежит конфиг?
Если вы не пишете три строчки на каком-нибудь PHP, у вас всегда есть файл, в котором описаны настройки проекта, его зависимости и способ сборки.
В node.js это package.json, в Java, Scala, Groovy это pom.xml, build.xml или build.gradle, в C это makefile и т.д.
Для Spring Boot это единственный конфиг, который вам реально необходим и это даже не обязательно XML, так что 100500 конфигов в Java это действительно миф.
BDA>Я не хочу раздувать холивор, но про Джаву я давно знаю, что это способ нагнать важности девелопменту и раскрутить заказчика на бабки.
Вас кто-то дезинформировал.
BDA>А у меня цель противоположная — прототип написать как можно быстрее и дешевле.
Вы сейчас приводите субъективно-эмоциональные аргументы, даже не попытавшись адекватно оценить предложенное решение. Это как-то не вяжется с утверждением, что вы не хотите разводить холивар. Хотите обсудить решение предметно, давайте обсудим. Если вам оно не интересно просто потому, что у вас сложилось предвзятое отношение насчет платформы, которую вы не очень хорошо знаете — желаю удачи с поиском того, что подойдет вам больше.
Re[3]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Если это миф, то почему по вашей же ссылке лежит конфиг? Я не хочу раздувать холивор, но про Джаву я давно знаю, что это способ нагнать важности девелопменту и раскрутить заказчика на бабки. А у меня цель противоположная — прототип написать как можно быстрее и дешевле. И если только не окажется, что в Спринг встроена поддержка виртуальных баз, нахрен мне это счастье — ПОМы, Мавены и прочее. Надо у жены спросить, она с этим Спрингом хорошо знакома.
Может мой опыт пригодится. У меня последний опыт работы с Java был на уровне консольных прикладух, функций для Oracle и чуть-чуть веб на уровне понимания что такое сервлеты.
Последние две недели осваиваю стек Web.
Итак, накачал себе Netbeans и Glassfish, а база у меня Oracle.
Netbeans вообще ничем внимания не привлек — обычная и понятная IDE.
Первым делом волевым усилием освоил maven — репозиторий пакетов. Раньше jar-ы нужно было качать отовсюду самому, а теперь они все сами скачиваются и ставятся с зависимостями.
Glassfish тоже в общем-то обычный контейнер сервлетов, но с отладчиком Netbeans стыкуется криво, есть ньюансы.
В паре Netbeans и Glassfish тупят, тормозят, жрут очень много памяти и иногда вылетают с ее нехваткой.
Spring для J2EE нынче в мейнстриме. Но осваивается тяжело. Конфиги реально бесят. Но я пострадал пару дней, потом порог как-то сам собой перешагнулся и все стало вполне понятно. Принципы REST, DI, IoC, MVC и прочие абревиатуры мне знакомы из .NET, так что с ними проблем не возникло. В общем, Spring-ом надо просто переболеть, дальше к нему образуется стойкий иммунитет.
Для клиента по наводке Булата пробую Webix. Копаю неполный второй день, и могу сказать, что он мне понравился.
Так что Java как вариант — вполне себе. Но нужна хорошая рабочая станция.
Re[4]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Есть схема БД, которая определяется юзером. Сама юзерская БД примитивная (всего несколько типов колонок), но все же БД. Ее нужно замапить на сервере на какой-нибудь мускул. Проблема в том, что стираться ничего не должно (бесконечной глубины Undo). Отсюда следует, что простейшее решение — создавать/менять/убивать таблицы в настоящей БД один в один с виртуальной юзерской — немного не катит (?), нужны метаданные.
Есть уже готовый бесплатный SharePoint Foundation. Делает все что нужно. В 2013 можно рендеринг таблиц\форм на свои контролы переписать. Встроенная версионность есть.
Правда серьезные ограничения на количество данных. Но если все руками забивать, то вполне хватит.
Re[3]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
G>>Есть уже готовый бесплатный SharePoint Foundation.
BDA>Он не является фреймворком, и этого достаточно. Но, между нами, он еще и редкое УГ.
А вам шашечки или ехать? Все что описано — умеет изкаропки, а что еще для прототипа надо?
Re[5]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Он не является фреймворком, и этого достаточно. Но, между нами, он еще и редкое УГ.
G>>А вам шашечки или ехать? Все что описано — умеет изкаропки, а что еще для прототипа надо?
BDA>Я же сказал, он не является фреймворком. Сделать с ним ничего непредусмотренного неизвестными индусами нельзя, развивать в нужном направлении нельзя, можно только поставить и наслаждаться «искаропочностью»....
Плохому танцору... ну ты понял.
BDA>Короче, я шарик раньше сам продавал кому хочешь, мне его продавать не надо. Я скорее на брейнфаке буду программировать СУБД под свою задачу, чем соглашусь еще раз коснуться этого отстоя.
Так тебе всетаки шашечки, а ехать и не нужно? Или ты думаешь, что запилив свою метамодель на СУБД с версионностью каждой строки у тебя прямо офигенский результат получится и язык запросов не жуже SQL? И сколько ты собрался это делать? Год? Два?
BDA>P.S. И на всякий случай: установить ШП не значит создать прототип чего бы то ни было, кроме как инсталляции ШП. Которая у меня, к слову, и так имеется.
Ну и в чем тогда проблема? Создал сайт, колонки, списки — готовый прототип, остальное на angular рисуешь. Потом шарик выкидываешь и пишешь полноценный бекэнд с логикой любой сложности.
Re[5]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
G>>Плохому танцору... ну ты понял.
BDA>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Но это мы опять о танцорах. А теперь давай к реальности. Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице), и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
BDA>>>Короче, я шарик раньше сам продавал кому хочешь, мне его продавать не надо. Я скорее на брейнфаке буду программировать СУБД под свою задачу, чем соглашусь еще раз коснуться этого отстоя. G>>Так тебе всетаки шашечки, а ехать и не нужно? Или ты думаешь, что запилив свою метамодель на СУБД с версионностью каждой строки у тебя прямо офигенский результат получится и язык запросов не жуже SQL? И сколько ты собрался это делать? Год? Два?
BDA>Зачем мне свой язык запросов? Я что, Майкрософт, с ее поиском фатальных недостатков? Если бы ШП давал SQL-интерфейс к [AllUserData], включая документацию, я бы, МОЖЕТ БЫТЬ, закрыл глаза на его общую упячность. А совсем без программирования у них тоже не получится — возьмем, например, такую ма-а-а-аленькую проблемку, как отказ считать результат агрегирующих функций (то, что во вьюхах идет как Total или типа того, не помню) гражданами первого класса, то есть элементами списков. Все-таки, dogfooding'а у них не было, это говорит каждый, кто пробовал запилить на шаре хотя бы элементарный багтрекер.
Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Re[8]: Какие фреймворки использовать для прототипа?
Здравствуйте, gandjustas, Вы писали:
BDA>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно? G>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
UPDATE Operations
SET Priority="High"
WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать.
Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
G>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов:
При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал.
И только с приемами типа такого можно достичь скорости, которой хватит для реального применения. У меня даже остался набор инструментов, который все это делает. Во всех остальных случаях можно просто взять бесплатную CMS'ку (для портала) или Access (для построчного редактирования) и не иметь себе и другим мозгА.
G>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Да, много чего можно взять, если задаться целью купить у Микрохвоста.
G>Но это мы опять о танцорах. А теперь давай к реальности.
Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице)
Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
G>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных. G>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно? G>>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
BDA>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>
BDA>UPDATE Operations
BDA>SET Priority="High"
BDA>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>
Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль.
BDA>То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать. BDA>Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю.
G>>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
BDA>Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов: BDA>Image: updatesingle_vs_updatebatch-600x106.png
Не пойму что ты хочешь сказать. Что невозможно отправить один батч на сервер чтобы обновить много записей? Это можно сделать вообще-то.
BDA>При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Никаких 30 секунд таймаута на одну операцию с базой нет. 30 секунд есть для батча клиентской объектной модели и 60 сек общего времени для sandbox. Ни тем, ни другим, никто не заставляет тебя пользоваться.
Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
BDA>Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
Работай, кто же мешает? Поэлементно, как в excel. Никто никогда и не говорил, что списки SharePoint должны быть похожи на таблицы в БД.
Для пользовательских операций — добавления, обновления, удаления элементов и фильтров по колонкам функционала более чем достаточно.
Для твоей задачи нужно что-то еще? Ты же не написал какие запросы будут.
BDA>На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал.
Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом.
Если пользователю не надо эту операцию делать каждые 30 секунд, то проблем никаких. А если надо, то делается очередь и уже асинхронно на сервере обрабатывается.
Проблема у тебя исключительно надуманная. Синхронно делать массовые операции в "простой таблице" — в реальности такой сценарий не существует.
Попробуй реализовать свое хранилище с версионностью на каждое изменение и сделай там массовые операции.
G>>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение. BDA>Да, много чего можно взять, если задаться целью купить у Микрохвоста.
Тебе же прототип нужен, а CRM прекрасно работает 90 дней в триале. За 90 дней ты не сможешь сделать прототип?
SP Foundation вообще бесплатен.
Если не нравится MS, то возьми 1C. Там тоже CRM есть.
Если тебе нужен прототип, то зачем вообще программировать хранилище и UI? Возьми готовое.
G>>Но это мы опять о танцорах. А теперь давай к реальности. BDA>Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
Да напиши код, в чем проблема? Пусть медленно работает, скрась ожидание пользователя прогресс-баром. С чего ты взял что это вообще проблема с точки зрения пользователя или бизнеса? Ты лишь пишешь, что система, которая имеет версионность на каждую запись внезапно работает медленнее при массовых апдейтах, чем СУБД без такой версионности.
>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
1С, Access, CRM генерируют, но в них версионности нет, максимум лог изменений отдельных полей без отката. SP и другие CMS обычно не генерируют (бывают варианты, но чаще в одной таблице все лежит), зато чаще всего версионность есть.
>>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
BDA>Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
Твоя ситуация называется "думаю что знаю". Вот ты не знаешь как сделать хранилище. Ты не знаешь как устроены CMS и почему. При этом ты думаешь что знаешь почему SP плохой и как на нем делать решения. Увы, пока у тебя хобот в жопе, пока ты думаешь что знаешь, ты ничему не научишься.
Тут два варианта, или ты пойдешь учиться, или сделаешь свой прототип хранилища. Причем целенаправленная учеба займет от силы месяц part-time, а свое хранилище будешь полгода пилить фуллтайм до первого рабочего состояния. А потом наступит просветление, что 90% функций, которые ты хотел заложить, будут сильно тормозить, но в реальности не встретятся и ты получишь 5% возможностей SQL и завернешь в модный нынче JSON.
G>>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных. G>>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
BDA>Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
Ты же не рассказал что требуется. Все что ты сказал — версионность каждого изменения и конструктор для списков с простыми полями. Бесплатный SP делает именно это.
А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
Re[10]: Какие фреймворки использовать для прототипа?
Здравствуйте, gandjustas, Вы писали:
BDA>>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>>
BDA>>UPDATE Operations
BDA>>SET Priority="High"
BDA>>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>>
G>Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
Так ведь это — принципиальная разница. Я не знаю, помните ли вы, как SQL-сервера боролись с продуктами типа dBase, FoxBase, Clipper. Было это 20 лет назад. Я был молод, но поскольку читал правильную прессу, этот момент очень хорошо отследил. Дибейзовщина именно так и была устроена («сначала запрос, потом апдейт») и просрала все полимеры по следующим причинам:
1. Канал между СУ и клиентами был перегружен. По мере роста нагрузки сеть забивалась, люди ставили более мощное сетевое оборудование, но рост пропускной способности имел лимит в несколько раз. Когда этот лимит был исчерпан, клиенты (т.н. АРМы) начинали проводить время в ожидании и СДЕЛАТЬ НЕЛЬЗЯ БЫЛО НИЧЕГО.
2. Пока осуществлялся запрос, другие могли взять и выполнить апдейт, приводя базу в неконсистентное состояние.
3. Пытаясь пофиксить п. 2, разработчики лочили базу, в результате чего каждый клиент становился узким местом.
SQL решил все эти проблемы одним махом.
1. После того, как данные перестали гоняться на сервер, нагрузка упала на много-много десятичных порядков. Сравните байты и килобайты запросов и мегабайты и гигабайты данных, которые ходят туда и обратно.
2. Запрос транзакционен и консистентность гарантируется.
3. Ни один клиент не мог быть больше узким местом.
Шаропоинт, по сути своей, это Дибейз наших дней. Все заточено под архитектуру, которая была заведомо проигравшей 20 лет назад. Если история кого-то ничему не учит, то он будет наступать на грабли, пока не поумнеет. Причем, в оправдание Шаропоинта можно сказать, что его, может быть, никогда и не проектировали ни под какую серьезную работу с данными. Схема «один специально обученный человек ведет списки, все остальные читают» — потолок его табличных возможностей. Создатели его и не продвигают для решения таких задач, как я описал. А вы — продвигаете. Не понимаю, зачем я трачу время на то, чтобы вправить мозги одному-единственному человеку, когда я ищу кого-нибудь, кто мне самому мозги бы вправил.
G>Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль.
... G>Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю.
... G>Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
Так вот, про вправку мозгов. Я не знаю, как это сделать даже без версионности, чтобы тех граблей, как в Шарике не было, и я ищу кого-нибудь, кто лучше меня и вас разбирается в обработке данных, и подскажет какую-нибудь идейку.
В чистом итоге пока следующее. Готовых решений нет. ORM точно не нужен. Можно попробовать паттерн EAV. Можно попробовать сделать sparse-колонки. Можно мапить таблицы 1:1 и по мере роста их числа прибегнуть к шардингу.
BDA>>Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов: BDA>>[--url=http://apmblog.dynatrace.com/wp-content/updatesingle_vs_updatebatch-600x106.png]Image: updatesingle_vs_updatebatch-600x106.png[/url] G>Не пойму что ты хочешь сказать. Что невозможно отправить один батч на сервер чтобы обновить много записей? Это можно сделать вообще-то. G>Никаких 30 секунд таймаута на одну операцию с базой нет. 30 секунд есть для батча клиентской объектной модели и 60 сек общего времени для sandbox. Ни тем, ни другим, никто не заставляет тебя пользоваться.
Что вы не понимаете? Что система, которая на 100 записях при ПАКЕТНОЙ обработке данных (то есть, правильно написанном запросе) заставляет клиента ждать по 2 секунды, немного не то, что нужно для решения практических задач? Не понимаете — и не понимайте, мне вообще пофиг.
BDA>>На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал. G>
Вы зря смеетесь, потому, что это было и остается единственным решением, которое позволяет людям, вляпавшимся в это Г, хоть как-то работать. Поскольку я, даже не имея исходников, поменял механизм работы с «дибейзовского» на «скульный», превратив Шаропоинт в истинно клиент-серверный продукт. Ничего более хакерского я в своей жизни не делал, а по сложности это сравнимо с заменой двигателя автомобиля на полном ходу. Впрочем, не буду мешать, поскольку чтобы понять весь пафос, надо хоть какую-то культуру обработки данных иметь, а из этого:
G>Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом.
видно, что вы даже суть SQL не понимаете.
Я хочу подчеркнуть, что я сюда пришел за советом, поскольку не знаю, как свою задачу решить, а не чтобы кого-то попинать. Дорогое удовольствие вас пинать, поскольку времени вагон нужен. И в дальнейшем пинайте себя сами, а я буду общаться только на тему своей задачи. Можете считать ее надуманной, пожалуйста, раз вы так лихо делите транзакцию на запрос и апдейт, и производите обработку данных на клиенте, вы ее и не поймете никогда.
>>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие. G>Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
Например, отказаться от табличных СУБД.
Дальше скипаю, перехожу к сути:
G>А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
Если не пилить свой язык запросов, свою ОМ, свой API, и все остальное, что напилили в ШП, а ограничиться задачей, которую я достаточно подробно описал (очень простая виртуальная БД, но написанная не через жопу... то есть, клиентский код, как ШП), то ее решение и будет прототипом, который можно создать относительно малыми силами. Дальше можно прикрутить к нему мои специфические хотелки.
Re[11]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>>>
BDA>>>UPDATE Operations
BDA>>>SET Priority="High"
BDA>>>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>>>
G>>Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
BDA>Так ведь это — принципиальная разница...
Все это нерелевантно предмету обсуждения.
BDA>1. После того, как данные перестали гоняться на сервер, нагрузка упала на много-много десятичных порядков. Сравните байты и килобайты запросов и мегабайты и гигабайты данных, которые ходят туда и обратно. BDA>2. Запрос транзакционен и консистентность гарантируется.
Когда речь идет о прототипе, то какая разница?
BDA>3. Ни один клиент не мог быть больше узким местом.
Это вообще ортогонально способу делать апдейты. Залочить базу или основные рабочие таблицы можно и SQL Server, особенно если мета-модели в базе.
BDA>Шаропоинт, по сути своей, это Дибейз наших дней. Все заточено под архитектуру, которая была заведомо проигравшей 20 лет назад. Если история кого-то ничему не учит, то он будет наступать на грабли, пока не поумнеет. Причем, в оправдание Шаропоинта можно сказать, что его, может быть, никогда и не проектировали ни под какую серьезную работу с данными. Схема «один специально обученный человек ведет списки, все остальные читают» — потолок его табличных возможностей. Создатели его и не продвигают для решения таких задач, как я описал. А вы — продвигаете. Не понимаю, зачем я трачу время на то, чтобы вправить мозги одному-единственному человеку, когда я ищу кого-нибудь, кто мне самому мозги бы вправил.
Это лишь твое мнение, никому кроме тебя не нужное. Есть проблема сделать прототип с простыми списками и полями — SP подходит. Все апелляции к архитектуре — ни о чем. Аргумент о том, что нельзя сделать массовый апдейт одним запросом тоже ни о чем, есть 100500 способов получить аналогичный результат, и они все подходят для прототипа.
G>>Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль. BDA>... G>>Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю. BDA>... G>>Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
BDA>Я не знаю, как это сделать даже без версионности, чтобы тех граблей, как в Шарике не было
При этом у шарика хреновая архитектура... ну да, мы поняли.
BDA>В чистом итоге пока следующее. Готовых решений нет. ORM точно не нужен. Можно попробовать паттерн EAV. Можно попробовать сделать sparse-колонки. Можно мапить таблицы 1:1 и по мере роста их числа прибегнуть к шардингу.
Ты не о том думаешь. Ты лучше думай о версионности, как сделать чтобы каждый апдейт создавал новую запись и не ломал связи. А как придумаешь, тогда попробуй сделать массовый апдейт, чтобы он не лочил всю базу и сохранял консистентность\независимость транзакций. А уже потом на это накручивай flexible schema. Только вот прототип будет нескоро...
BDA>Что вы не понимаете? Что система, которая на 100 записях при ПАКЕТНОЙ обработке данных (то есть, правильно написанном запросе) заставляет клиента ждать по 2 секунды, немного не то, что нужно для решения практических задач? Не понимаете — и не понимайте, мне вообще пофиг.
Я не знаю что там за система, я видел и обычные реляционные схемы, которые по 5 сек работают на одиночном апдейте работают. 20 мс на обработку одной записи с правами и версионностью — вполне ок. Считаешь что это медленно — сделай быстрее.
BDA>Вы зря смеетесь, потому, что это было и остается единственным решением, которое позволяет людям, вляпавшимся в это Г, хоть как-то работать. Поскольку я, даже не имея исходников, поменял механизм работы с «дибейзовского» на «скульный», превратив Шаропоинт в истинно клиент-серверный продукт. Ничего более хакерского я в своей жизни не делал, а по сложности это сравнимо с заменой двигателя автомобиля на полном ходу. Впрочем, не буду мешать, поскольку чтобы понять весь пафос, надо хоть какую-то культуру обработки данных иметь, а из этого:
Я совсем не зря смеюсь, потом что большего бреда я вообще не слышал. Ты потратил много денег клиента, привел его ферму в неподдерживаемое состояние (апдейты не поставишь, как апгрейдить — неясно, в поддержку МС звонить бесполезно). В итоге экономический эффект от твоих действий — отрицательный, то есть насрал больше, чем пользы принес. И ты еще умудряешься этим гордиться. И самое главное, что твои действия можно было бы заменить несколькими строками JS, да они еще и лучше работали бы.
G>>Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом. BDA>видно, что вы даже суть SQL не понимаете.
Видимо я получше тебя понимаю, причем не только SQL, но и потребности пользователей и бизнес.
>>>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>>>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие. G>>Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
BDA>Например, отказаться от табличных СУБД.
Если ты пользователю выставляешь таблицы со связями, то как ты будешь джоины делать?
Тебе вообще зачем такая база? Ты какую бизнес-задачу решаешь?
BDA>Дальше скипаю, перехожу к сути:
G>>А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
BDA>Если не пилить свой язык запросов, свою ОМ, свой API, и все остальное, что напилили в ШП, а ограничиться задачей, которую я достаточно подробно описал (очень простая виртуальная БД, но написанная не через жопу... то есть, клиентский код, как ШП), то ее решение и будет прототипом, который можно создать относительно малыми силами. Дальше можно прикрутить к нему мои специфические хотелки.
Прототипом чего?
Из всего что есть в мейнстриме вам попалась самая 
