необходимо в so-библиотеке… определить инициализацию Application в секции initialization и завершение в finalization
{$IFDEF FPC}
initialization
Application.Initialize;
finalization
Application.Terminate;
end.
{$ENDIF}
Удивил момент что надо инициировать Application в каждой библиотеке. В Delphi/VCL, насколько я помню, Application глобальный singleton объект и повторная инициализация смысла не имеет.
Машинариум кажется на флэше. Огромный квест с кучей ресурсов запаковали во флэш — это о границах технологии, оно не ограничивалось мелкими проектами и/или игрухами. Но всеми приходит конец. RIP
В составных первичных ключах есть еще один недостаток. Зачастую PK делаются не только для того чтобы обеспечить уникальность, но и для того чтобы сослаться на таблицу из дочерней foreign key-м. В таком случае в дочернюю таблицу придется тащить не одно, а два поля, что означает перерасход места под таблицу.
Ну и как заметил GooG2e, бывают ситуации когда естественные ключи перестают быть уникальными. Имхо, достаточно столкнуться с одним таким случаем на своей практике в проде на большой базе, чтоб перестать даже думать использовать естественные ключи.
Очень крутой тул! Может быть кто-то в курсе, нет ли чего-то подобного под windows?
Вчера отлаживал сетевое взаимодействие клиента с сервисом, ничего умнее чем выключение сетевого подключения (пардон за тавтологию) в голову не пришло. Довольно муторно и неудобно.
Как-то снимал квартиру в таком месте, где двор соседнего здания освещался мощным фонарем с датчиком освещения. Один раз проснулся от периодических щелчков реле и всполохов на потолке. Около 3 ночи, рассвет, по ясному алеющему небу плывут красивые плотные облака, чуть подсвеченные скраешку восходящим солнцем. И в такт этой красоте мигает и щелкает фонарь, зараза, с довольно рандомным периодом 3-5 минут.
Понятно что все можно настроить. В первую очередь петлю гистерезиса на включение/выключение, сделать интегрирование показаний (опять же вопрос за какой период времени?), таймеры какие-то на смену состояния. Сколько это все отлаживать, где гарантия что будет работать при всех погодных условиях?
Уснуть уже не удалось, с тех пор я не сторонник всяких кривых датчиков освещенности :)
Справедливости ради, за 4-5 месяцев такой баг наблюдался только один раз.
Все очень сильно зависит как от архитектуры словаря базы, так и принципов хранения данных.
Postgres фактически меняет только метаданные о таблице, никак не затрагивая самих данных. Поскольку Postgres это версионная СУБД, то при заполнении нового столбца значениями, будут создаваться новые версии строк, но точно также они бы создавались при изменении значений «старых» столбцов. С одной стороны мы растягиваем во времени процесс увеличения места под таблицу и делаем это только по необходимости, но платим за это тем, что в таблице остаются старые версии строк даже когда они нам уже не нужны. Таким образом если мы проставим значения нового столбца для всех строк, то таблица может вырасти более чем в 2 раза и придется ее жать vacuum'ом. И да, ему нужен эксклюзивный доступ к таблице. Так что проблема та же, просто она откладывается на потом.
В Oracle добавление нового поля тоже выполняется быстро. Там фишка в том что «хвостовые» значения столбцов не хранятся в блоках данных пока их значения null. Но при попытке установки значения, если в блоке не хватит места, то «хвост» строки уедет в другой блок, т.н. chained rows и чтобы прочитать строку придется физически читать 2 блока. Если таких строк много, то производительность может упасть в 2 раза. И да, придется фактически пересоздавать таблицу (alter table move...) что тоже требует эксклюзивной блокировки на таблицу и требует больших ресурсов.
Так что хотя везде свои тонкости, закон сохранения никто не отменял
>Вот эти архитектурные украшения. Оказывается, так «скругляют» углы для того, чтобы граждане были заинтересованы всё же добежать до туалета:
Слышал версию, что «безугловая» городская среда создавалась в средние века как защита от наемных убийц — чтобы не было возможности устроить засаду за углом.
Смутно помнится что была команда, которая копировала себя адресом выше и передавала управление на этот адрес. Занеся и запустив команду по младшему адресу получали зависший комп с полосатым экраном. С некоторой натяжкой можно считать самым коротким «червём» :) Как сказано неоднократно выше, это было возможно благодаря развитой и разнообразной системе адресации
Спасибо за статью, будет очень интересно почитать продолжение. Сами смотрели на эту технологию (в основном для обновления кода). Но без автоматизации процессов, в ручном режиме, показалось слишком сложным следить за корректной версионностью объектов. Если бы это интегрировать с какой-то системой контроля версий…
Спасает ли использование EBR от локов во время/после компиляции на рабочей системе?
Удивительно, но нет ни одной байки при NDD — norton disk doctor.
Был в свое время мс1251 c 20-мегабайтным диском отечественного производства. Диск был размером с буханку хлеба, подключался через внешний контроллер, который втыкался в слот компа. Понятно что все это работало мягко говоря не очень надежно — контакты контроллера и внешней памяти норовили сбойнуть, вешая комп.
Неудивительно что в какой-то момент диск логически развалился так, что перестал грузиться и показывать файловую структуру. Поскольку содержимое было безумно жалко — там всё установлено, настроено, проекты, лабораторки, и т.д. и т.п., заморочился восстановлением. А автомате NDD сказал что на диске какая-то каша, восстановлению не подлежит. Пришлось колупаться в секторах диска низкоуровневым редактором из состава того же NDD. Как раз под рукой была книга с описанием устройства FAT, подробности уже не помню, но служебные секторы удалось восстановить местами побайтно. После этого проникся к Нортону еще большим уважением
Удивил момент что надо инициировать Application в каждой библиотеке. В Delphi/VCL, насколько я помню, Application глобальный singleton объект и повторная инициализация смысла не имеет.
nicky7
bpl это расширенная версия dll с точки зрения интерфейса — к стандартным функциям добавлены дополнительные под нужды среды/vcl
PS: Очень впечатлён! Мне казалось что портирование сколько-то сложного проекта задача просто непосильная.
Ну и как заметил GooG2e, бывают ситуации когда естественные ключи перестают быть уникальными. Имхо, достаточно столкнуться с одним таким случаем на своей практике в проде на большой базе, чтоб перестать даже думать использовать естественные ключи.
Вчера отлаживал сетевое взаимодействие клиента с сервисом, ничего умнее чем выключение сетевого подключения (пардон за тавтологию) в голову не пришло. Довольно муторно и неудобно.
Понятно что все можно настроить. В первую очередь петлю гистерезиса на включение/выключение, сделать интегрирование показаний (опять же вопрос за какой период времени?), таймеры какие-то на смену состояния. Сколько это все отлаживать, где гарантия что будет работать при всех погодных условиях?
Уснуть уже не удалось, с тех пор я не сторонник всяких кривых датчиков освещенности :)
Справедливости ради, за 4-5 месяцев такой баг наблюдался только один раз.
Postgres фактически меняет только метаданные о таблице, никак не затрагивая самих данных. Поскольку Postgres это версионная СУБД, то при заполнении нового столбца значениями, будут создаваться новые версии строк, но точно также они бы создавались при изменении значений «старых» столбцов. С одной стороны мы растягиваем во времени процесс увеличения места под таблицу и делаем это только по необходимости, но платим за это тем, что в таблице остаются старые версии строк даже когда они нам уже не нужны. Таким образом если мы проставим значения нового столбца для всех строк, то таблица может вырасти более чем в 2 раза и придется ее жать vacuum'ом. И да, ему нужен эксклюзивный доступ к таблице. Так что проблема та же, просто она откладывается на потом.
В Oracle добавление нового поля тоже выполняется быстро. Там фишка в том что «хвостовые» значения столбцов не хранятся в блоках данных пока их значения null. Но при попытке установки значения, если в блоке не хватит места, то «хвост» строки уедет в другой блок, т.н. chained rows и чтобы прочитать строку придется физически читать 2 блока. Если таких строк много, то производительность может упасть в 2 раза. И да, придется фактически пересоздавать таблицу (alter table move...) что тоже требует эксклюзивной блокировки на таблицу и требует больших ресурсов.
Так что хотя везде свои тонкости, закон сохранения никто не отменял
Слышал версию, что «безугловая» городская среда создавалась в средние века как защита от наемных убийц — чтобы не было возможности устроить засаду за углом.
Спасает ли использование EBR от локов во время/после компиляции на рабочей системе?
Был в свое время мс1251 c 20-мегабайтным диском отечественного производства. Диск был размером с буханку хлеба, подключался через внешний контроллер, который втыкался в слот компа. Понятно что все это работало мягко говоря не очень надежно — контакты контроллера и внешней памяти норовили сбойнуть, вешая комп.
Неудивительно что в какой-то момент диск логически развалился так, что перестал грузиться и показывать файловую структуру. Поскольку содержимое было безумно жалко — там всё установлено, настроено, проекты, лабораторки, и т.д. и т.п., заморочился восстановлением. А автомате NDD сказал что на диске какая-то каша, восстановлению не подлежит. Пришлось колупаться в секторах диска низкоуровневым редактором из состава того же NDD. Как раз под рукой была книга с описанием устройства FAT, подробности уже не помню, но служебные секторы удалось восстановить местами побайтно. После этого проникся к Нортону еще большим уважением