ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Почему мы используем Common Lisp в автоматизации бизнеса
19 сообщений из 94, страница 4 из 4
  4  все
Почему мы используем Common Lisp в автоматизации бизнеса
    #38478970
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
У меня добавление поля в Базе данных или изменение набора параметров метода как правило тоже
не ведут к каким-то большим изменениям рабочего кода.
Не понимаю, о чём это, т.к. даже не знаю, какой базой вы пользуетесь. Давайте считать, что вот у нас есть база данных. Допустим, мы поддерживаем форум sql.ru и нам нужно добавить в таблицу сообщений новое поле "рейтинг". Причём, не рассматриваем веб-сервер и т.п. Чисто сами данные. Вот есть таблица messages и надо добавить поле rating. Как мы будем это делать с ALTER TABLE и без него, распишите в двух абзацах, если не трудно.
...
Рейтинг: 0 / 0
26.11.2013, 20:16
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38478983
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
MasterZiv,
Не, ну любому разработчику БД в общем это преимущество должно быть очевидно -- пересоздал процедуру или пакет -- и он уже все, работает. Никаких компиляторов, линкеров, WAR-ов и прочей фигни.

Однако, не получить внятного подтверждения этого у Arm79 и он даже не понял, чего от него хотят. Вот теперь с рубистом посмотрим, как будет. Как только получим, далее постараюсь по аналогии объяснить, зачем нужна горячая замена. Или, может быть, дело в том, что у них экосистема оформлена в виде множества отдельных кусочков, как unix text tools? Но как это выяснить?
...
Рейтинг: 0 / 0
26.11.2013, 20:24
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38478990
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
рубист,
да, еще добавлю .......
Если был метод

obj.method('value1', 'value2')


и его реализация изменена на

obj.method('value1', 'value2', named_param: 'value3')


то везде где он вызывается ничего не будет сломано, все будет работать.

Да, я это и имел в виду, именно так в лиспе и можно делать.
...
Рейтинг: 0 / 0
26.11.2013, 20:30
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479012
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arm79
Участник
buddenвнятного подтверждения этого у Arm79 и он даже не понял, чего от него хотят

Ну, до банальных оскорблений мне кажется, опускаться не стоит. С какой это стати я не понял? Как человек, работающий с MS SQL много лет, не понимает ALTER и так далее?

Просто в отличие от вас, у меня есть опыт сопровождения больших промышленный систем. И я категорически против любых Alter на бою без предварительного тестирования, и скриптов отката. Система работы, где правки идут сразу на бою и силами разработчиков, вызывает только усмешку.

Поэтому я и заявил, что заявленных вами преимуществ языка, лично мне не хватает, чтобы начать учить CL.

Учитесь быть вежливее, я ведь вас не оскорблял.
...
Рейтинг: 0 / 0
26.11.2013, 20:57
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479013
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Просто в наше время - разработчик перестал принадлежать предприятию. Чаще он - сторонняя организация
и следовательно не несёт прямой ответсвтенности за последствия alter-ов. И пускать его к консоли
это всё одно што обизяне гранату дать. Песочница - другое дело.
...
Рейтинг: 0 / 0
26.11.2013, 21:00
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479055
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
Arm79, я вас не оскорблял. Оскорбление - это из уголовного кодекса.

Если вас так задевает моё замечание, что вы чего-то не поняли, то давайте формулировать это так: вы поняли, что я хочу от вас формулировки нужности alter-а, но не захотели разговаривать об этом, потому что просчитали, куда дальше пойдёт тема и сочли это неинтересным. Так будет нормально?
...
Рейтинг: 0 / 0
26.11.2013, 21:44
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479060
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
mayton, все мы делаем alter table на боевом сервере, в т.ч и Arm79. Возможно, мы не пишем буквально этих слов. Возможно, у нас скрипт или какое-то средство, где мы ставим галочку мышью, чтобы поле добавилось. Возможно, мы делаем ЭТО ночью, когда никто не видит. Но мы ЭТО делаем, давайте не будем стесняться. И мы делаем ЭТО не только в песочнице, но и с боевой базой.

Нюансы, как мы это делаем не имеют значения. Я спрашиваю о том, как бы мы жили, если бы у нас _не_было_вообще_ alter table?

Могу и вам тоже намекнуть.

Вот ночь на дворе. Все спят. Сидит админ. У него таблица. В ней 22 поля и миллиард записей.
Ему надо добавить поле в таблицу. Всё уже проверено на песочнице и т.п.

Далее распишите два варианта:
вариант 1. Нормальная система с alter table.
вариант 2. Статическая система без alter table.

Как действовать в обоих случаях, какой случай удобнее и почему?
...
Рейтинг: 0 / 0
26.11.2013, 21:52
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479128
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
buddenЯ спрашиваю о том, как бы мы жили, если бы у нас _не_было_вообще_ alter table?NoSQL?
...
Рейтинг: 0 / 0
26.11.2013, 23:27
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479214
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
рубист
Участник
buddenУ меня добавление поля в Базе данных или изменение набора параметров метода как правило тоже
не ведут к каким-то большим изменениям рабочего кода.
Не понимаю, о чём это, т.к. даже не знаю, какой базой вы пользуетесь. Давайте считать, что вот у нас есть база данных. Допустим, мы поддерживаем форум sql.ru и нам нужно добавить в таблицу сообщений новое поле "рейтинг". Причём, не рассматриваем веб-сервер и т.п. Чисто сами данные. Вот есть таблица messages и надо добавить поле rating. Как мы будем это делать с ALTER TABLE и без него, распишите в двух абзацах, если не трудно.

Сори, база конечно же SQL. Обычно MySQL или PostgreSQL. библиотека ActiveRecord, которая реализует одноименный шаблон проектирование.
С Alter Table можно тремя вариантами.
1. Сделать изменения в таблице самому, в ручную. В коде изменений не нужно.
2. Написать скрипт миграции (используется чаще всего), он позволяет автоматизировать процесс и в случае проблем откатиться.
3. Если использовать не Activerecord, а Datamapper для работы с БД, то там достаточно добавить нужное поле непосредственно в коде. Нужно уточнить по документации, я Datamapper почти не использую.
Все три способа на прямую или косвенно запускают Alter Table.

Если нужно обойтись без Alter Table, то я вижу только два способа.
1. Сериализация атрибутов в одном из выделенных для этого полей таблицы. Добавление\удаление атрибута не затронет структуру SQL базы вообще. Здесь большой минусы - такие атрибуты будет сложно использовать в запросах, и их будет невозможно индексировать.
2. Использовать связку SQL и NoSQL (или только NoSQL) для атрибутов. На счет связки я не уверен, должна быть какая-то очень острая необходимость, чтобы выбрать такой вариант.

Немного про миграции.
Типичный скрипт миграции выглядит так: add_part_number_to_products.rb
Код: ruby
1.
2.
3.
4.
5.
6.
class AddPartNumberToProducts < ActiveRecord::Migration
  def change
    add_column :products, :part_number, :string
    add_index :products, :part_number
  end
end


выполняется командой > rake db:migrate
откат > rake db:rollback
Дополнительно можно указывать еще разные параметры типа STEP= или VERSION= для выполнения или отката на какую-то стадию или версию миграции.
Система сама следит за тем, какие миграции уже выполнены, какая текущая версия и т.д.

Метод change может быть заменен на два метода up и down если нужно отдельно описать возврат к прежнему состоянию.
Обычно это делается если идет не добавление поля, а его переименование.
...
Рейтинг: 0 / 0
27.11.2013, 03:07
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479717
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
рубист, я вообще-то имел в виду такой сценарий, позволяющий
добавить поле в базу SQL хотя бы без революций в программировании:

1. выгрузить данные из таблицы во внешний файл
2. уничтожить её (drop table)
3. создать её снова с новым полем (create table)
4. загрузить данные из внешнего файла

Если записей миллиард, то выгрузка-загрузка может оказаться
фатальной с точки зрения затрат времени и мы не сможем продолжать
жизнь нашей системы.

Никто меня не понял, значит, видимо, проблема на моей стороне.

Но идём дальше.

Получается, что alter table жизненно важен для приложений SQL, если не
предпринимать специальных и не вполне хороших мер.

Что есть alter table? Это и есть горячая замена определения класса (ну ладно, структуры).
Горячая не потому, что она делается на боевом сервере, а потому, что не нужно
останавливать базу и потому что сохраняются данные. Заменим мысленно слово table
на слово record, struct или class, а записи в таблице заменим мысленно на экземпляры класса.
Получится, будто бы мы в работающей программе поменяли определение типа, а данные
при этом сохранились. Новое поле заполнилось чем-то по умолчанию.

Кто-нибудь из не-лисперов согласен теперь с тем, что горячая замена кода
(или структуры данных) приложения играет большую роль в нашей жизни и
мы ей постоянно пользуемся?

Это я просто отвечаю на заявления, что "горячая замена не нужна". Вот она, горячая замена,
alter table. Нужна.
...
Рейтинг: 0 / 0
27.11.2013, 12:58
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479742
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
buddenвариант 2. Статическая система без alter table.
Я не понимаю что это такое. Что за термин?
...
Рейтинг: 0 / 0
27.11.2013, 13:10
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38479942
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
рубист
Участник
budden,
Понятно. В таком ключе "горячее" изменение кода конечно нужно.
...
Рейтинг: 0 / 0
27.11.2013, 14:35
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38480258
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
maytonbuddenвариант 2. Статическая система без alter table.
Я не понимаю что это такое. Что за термин?

Видимо, что-то вроде EAV иметься в виду...
...
Рейтинг: 0 / 0
27.11.2013, 16:51
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38480344
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
mayton, нет такого термина. Это просто антоним для "динамического", т.е. позволяющего что-то делать в рантайме. Видимо, неудачно я выразился.
...
Рейтинг: 0 / 0
27.11.2013, 17:57
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38480968
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
рубист, относительно миграций - мы сваяли аналогичную вещь, но мы не пытаемся делать откаты. Потому что откатить состояние базы просто-напросто не всегда возможно. Если дропнуто поле, то откатив миграцию, поле мы вернём, но данные в него - уже не вернём. Или вы хотите сказать, что эта система и данные тоже возвращает на место?
...
Рейтинг: 0 / 0
28.11.2013, 01:59
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38481010
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
рубист
Участник
budden,

Нет конечно, автоматически данные не вернутся.
Но в принципе миграцию можно написать так, чтобы при удалении поля\таблицы данные куда-то сохранялись и на откате их можно было вернуть.
Код миграции это обычный Ruby код и там можно использовать любые языковые конструкции и библиотеки.
...
Рейтинг: 0 / 0
28.11.2013, 03:15
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38481014
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
рубист
Участник
Справедливости ради надо заметить, что я не полагаюсь только на миграции
и при больших изменениях всегда с базы (или с ее части) снимаю дамп.
Не смотря на то, что сервера и так пишутся в бекап. В этом плане я перестраховщик :)
...
Рейтинг: 0 / 0
28.11.2013, 03:49
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38481745
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
budden
Участник
рубист, да, это ближе к сермяжной правде. Мы тоже так делаем при серьёзных изменениях. Смысл прост - при какой-то накладке можно мгновенно вернуть базу в рабочее состояние.

Касаемо "оболочек" для alter table, оформляющих их в виде классов руби - я подобными вещами в своё время переболел, но отказался от этого.

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

В итоге я пришёл к системе макросов для лиспа. Теперь пишу прямо в консоли что-нибудь такого типа
Код: sql
1.
2.
3.
4.
fse o.id, count(1) 
from M_OL_IJ_O 
where o.ref_type=M_IDOF(operation_type,'Отгрузка') 
group by o.id;



В этом запросе применено два макроса. Один - стандартный джойн между двумя таблицами, который постоянно используется.
Второй - говорящая константа. В итоге sql выполняет такой код:
Код: sql
1.
2.
3.
4.
select  o.id, count(1) 
from   operation_line as ol   inner join   OPERATION as o  on o.Id = ol.ref_operation  
where o.ref_type=36/*operation_type:'Отгрузка'*/ 
group by o.id



Стоя на слове M_OL_IJ_O, можно за одно нажатие клавиши попасть в определение.
Стоя на имени таблицы - можно попасть в описание этой таблицы с перечнем всех полей.
Когда в моём SQL коде возникает ошибка, открывается окно со сгенерированным кодом
(с расширенными макросами). Если в тексте сообщения указан номер строки и колонки,
курсор встаёт на эту строку и колонку (хотя иногда промахивается, но это уже баги).
Я нажимаю волшебную кнопку и попадаю в место исходника лиспа, откуда был
сгенерирован данный запрос. Это исключительно удобно для разработки! И когда
был слой поверх SQL, я не мог это реализовать.

На данный момент определено около 200 макросов - связки таблиц, сокращения для разного
рода операций с датами и числами, assert, вывод в логи. Часть макросов - это куски
конкретных процедур, повторяющиеся 2 или 3 раза, нужно переделать, чтобы они не светились
в общем пространстве имён макросов, это сделать можно, но нужно придумать, как это сделать
красиво, да и руки не доходят.

Интенсивно используемых - наверное, пара десятков.
...
Рейтинг: 0 / 0
28.11.2013, 14:05
| Ответить | Цитировать | Написать  
Почему мы используем Common Lisp в автоматизации бизнеса
    #38481781
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лагман
Участник
авторидентификаторы на Русском языке
...
Рейтинг: 0 / 0
28.11.2013, 14:18
| Ответить | Цитировать | Написать  
19 сообщений из 94, страница 4 из 4
  4  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Почему мы используем Common Lisp в автоматизации бизнеса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=38478990&tid=1341556]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 426ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 205ms
total:  735ms
созд. / загр.: 735ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]