Отличный плагин, который позволит управлять вашим браузером, используя стандартные сочетания клавиш Vim. Плагин так же доступен для Firefox.
воскресенье, 22 апреля 2012 г.
воскресенье, 15 апреля 2012 г.
Source code of DB objects
Представьте такую ситуацию: команда разработчиков работает над программой. При этом исходный код приложения нигде не хранится. Каждый программист с помощью специального декомпилятора выгружает нужный код из бинарника, работает с ним, а потом вновь собирает и отдает на дальнейшую разаработку коллегам.
Как вы думаете, это нормальная ситуация? Думаю, что нет. Но почему-то такой подход довольно часто применяется при разработке приложений БД. Объекты создаются и изменяются "наживую" прямо в БД. Большинство специализированных IDE предоставляют массу "удобных" инструментов для этого - поиск нужного объекта с помощью навигационного дерева, его модификация несколькими щелчками мыши и т.д. При этом об исходном коде мало кто задумывается - а при сборке версии часто используются утилиты, которые на основании кода текущей базы и кода базы продакшена генерируют диф-скрипт (для меня до сих остается загадкой как, т.к. альтер (таблицы например) можно сформировать множеством спосбов, все зависит от конкретного случая, от логики изменения и т.д.). Получается, что исходного кода базы как бы и не существует, он считается неким машинным кодом, трудно воспринимаемым человеком, который полностью отдается на откуп визуальным средствам разаработки. Программист работает не с функционалом своей СУБД, а с функционалом конкретной IDE, неким красивым и (как кажется первое время) удобным промежуточным слоем. При этом приходится изучать именно IDE, а не саму СУБД.
Стоит помнить, что после того как вы с помощью собственно написанного кода (выверенного, отформатированного по корпаративным стандартам, оформленного комментариями) создаете объект БД, этот код нигде не сохранится, вы потеряете его, а в замен получите, то что соберет за вас машина (IDE, специальные утилиты или библиотеки), опираясь на словарь данных БД. При этом теряется история изменения объектов (становится невозможным узнать/вспомнить кто, когда и зачем создавал/удалял/изменял тот или иной объект), могут возникать конфликты при совместной разработке и еще очень много чего.
Об этом можно почитать в "PLSQL Standards Developed for the PLSQL Starter Framework" в главе "Source Code Control":
Remember to never modify the PL/SQL stored in the database. Work from the source code file instead. Yes, modifying the compiled code inside the database is technically feasible, but a really bad idea. It is comparable in some ways to modifying Java bytecode or C object files.
и в главе "Data Models and DDL":
Most DDL is still created by hand. Make it clean, commented and readable, just like source code.
Напоследок приведу код создания простой таблицы в Oracle и то, что из него получается после выгрузки из БД различными утилитами.
Исходный код создания таблицы:
Как видно солянка полная, кто на что горазд.
Конечно это не значит, что нужно полностью отказаться от современных визуальных средств и работать в консольном редакторе. Самое главное работать именно с исходным кодом вашего приложения БД, контроллировать его самостоятельно, не отдавать на откуп машине. Исходный код приложений БД ничем не хуже кода Java или C++ приложений и требует к себе такого же обращения: форматирование, комментарии, контроль версий и т.д.
Несколько рекомендаций:
1. Весь код БД (DML, DDL, DCL, TCL и т.д.) необходимо хранить в репозитории (один объект = один файл);
2. Исходя из первого пункта, должна быть возможность собрать готовую к использованию "чистую" базу "с нуля", используя исходники из репозитория (нет необходимости делать дампы базы, вырезать ненужные(тестовые) данные и т.д.)
3. Править и компилировать код объекта БД нужно именно из файла (т.о. вместо навигатора по объктом БД вашей IDE станет актуален навигатор по файлам проекта в репозитории - найти файл, открыть на редактирование, накатить на базу).
Как вы думаете, это нормальная ситуация? Думаю, что нет. Но почему-то такой подход довольно часто применяется при разработке приложений БД. Объекты создаются и изменяются "наживую" прямо в БД. Большинство специализированных IDE предоставляют массу "удобных" инструментов для этого - поиск нужного объекта с помощью навигационного дерева, его модификация несколькими щелчками мыши и т.д. При этом об исходном коде мало кто задумывается - а при сборке версии часто используются утилиты, которые на основании кода текущей базы и кода базы продакшена генерируют диф-скрипт (для меня до сих остается загадкой как, т.к. альтер (таблицы например) можно сформировать множеством спосбов, все зависит от конкретного случая, от логики изменения и т.д.). Получается, что исходного кода базы как бы и не существует, он считается неким машинным кодом, трудно воспринимаемым человеком, который полностью отдается на откуп визуальным средствам разаработки. Программист работает не с функционалом своей СУБД, а с функционалом конкретной IDE, неким красивым и (как кажется первое время) удобным промежуточным слоем. При этом приходится изучать именно IDE, а не саму СУБД.
Стоит помнить, что после того как вы с помощью собственно написанного кода (выверенного, отформатированного по корпаративным стандартам, оформленного комментариями) создаете объект БД, этот код нигде не сохранится, вы потеряете его, а в замен получите, то что соберет за вас машина (IDE, специальные утилиты или библиотеки), опираясь на словарь данных БД. При этом теряется история изменения объектов (становится невозможным узнать/вспомнить кто, когда и зачем создавал/удалял/изменял тот или иной объект), могут возникать конфликты при совместной разработке и еще очень много чего.
Об этом можно почитать в "PLSQL Standards Developed for the PLSQL Starter Framework" в главе "Source Code Control":
Remember to never modify the PL/SQL stored in the database. Work from the source code file instead. Yes, modifying the compiled code inside the database is technically feasible, but a really bad idea. It is comparable in some ways to modifying Java bytecode or C object files.
и в главе "Data Models and DDL":
Most DDL is still created by hand. Make it clean, commented and readable, just like source code.
Напоследок приведу код создания простой таблицы в Oracle и то, что из него получается после выгрузки из БД различными утилитами.
Исходный код создания таблицы:
-- This is test_table CREATE TABLE test_table ( id NUMBER(38), -- PK value NUMBER(10,2), -- main value width NUMBER(5,0) -- main width value );DBMS_METADATA:
CREATE TABLE "OBJECTMAN"."TEST_TABLE" ( "ID" NUMBER(38,0), "VALUE" NUMBER(10,2), "WIDTH" NUMBER(5,0) )Tora:
CREATE TABLE objectman.test_table
(
id NUMBER(38)
, value NUMBER(10,2)
, width NUMBER(5)
)
TOAD Eclpise plugin:
create table test_table
(
id number(38),
value number(10,2),
width number(5)
)
Как видно солянка полная, кто на что горазд.
Конечно это не значит, что нужно полностью отказаться от современных визуальных средств и работать в консольном редакторе. Самое главное работать именно с исходным кодом вашего приложения БД, контроллировать его самостоятельно, не отдавать на откуп машине. Исходный код приложений БД ничем не хуже кода Java или C++ приложений и требует к себе такого же обращения: форматирование, комментарии, контроль версий и т.д.
Несколько рекомендаций:
1. Весь код БД (DML, DDL, DCL, TCL и т.д.) необходимо хранить в репозитории (один объект = один файл);
2. Исходя из первого пункта, должна быть возможность собрать готовую к использованию "чистую" базу "с нуля", используя исходники из репозитория (нет необходимости делать дампы базы, вырезать ненужные(тестовые) данные и т.д.)
3. Править и компилировать код объекта БД нужно именно из файла (т.о. вместо навигатора по объктом БД вашей IDE станет актуален навигатор по файлам проекта в репозитории - найти файл, открыть на редактирование, накатить на базу).
пятница, 30 марта 2012 г.
IDE for Oracle = vim + vorax
Install ruby:
Install vim with ruby support:
wget http://www.vim.org/scripts/download_script.php?src_id=14847
sudo yum install ruby ruby-devel rubygems sudo gem install antlr3 -r
Install vim with ruby support:
sudo yum install zlib-devel openssl-devel ncurses-devel cd Downloads git clone git://repo.or.cz/vim_mainline.git cd vim_mainline ./configure --enable-rubyinterp --with-features=huge make sudo make install
wget http://www.vim.org/scripts/download_script.php?src_id=14847
воскресенье, 25 марта 2012 г.
воскресенье, 11 марта 2012 г.
install Tora 2.1.3 on Fedora 16
Скачиваем исходники и достаем из архива:
Устанавливаем зависимые пакеты:
Понадобится переменная окружения LD_LIBRARY_PATH:
Теперь неменого подправим файл src/Makefile.am: в блоке BUILT_SOURCES нужно добавить moc_toawr.cpp:
Конфигурируем и собираем (предполагается, что на машине есть Oracle):
cd Downloads wget http://downloads.sourceforge.net/project/tora/tora/2.1.3/tora-2.1.3.tar.bz2?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Ftora%2Ffiles%2Flatest%2Fdownload&ts=1331490264&use_mirror=ignum tar -jxvf tora-2.1.3.tar.bz2
Устанавливаем зависимые пакеты:
su -c 'yum install qt-devel qscintilla-devel'
Понадобится переменная окружения LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
cd tora-2.1.3/
Теперь неменого подправим файл src/Makefile.am: в блоке BUILT_SOURCES нужно добавить moc_toawr.cpp:
... # files listed in BUILT_SOURCES are built before anything else. BUILT_SOURCES = \ moc_toawr.cpp \ moc_toabout.cpp \ moc_toalert.cpp \ ...
Конфигурируем и собираем (предполагается, что на машине есть Oracle):
./configure --prefix=/usr --with-oracle=$ORACLE_HOME --with-oracle-libraries=$ORACLE_HOME/lib make su -c 'make install'
пятница, 9 марта 2012 г.
Extract Oracle DDL to File
Простой скрипт для выгрузки DDL-кода Oracle-объекта в файл.
GenDDL.sql:
1) Пользователь (схема);
2) Объект;
3) Файл для выгрузки.
Пример запуска:
GenDDL.sql:
SET TERMOUT OFF
SET VERIFY OFF
SET ECHO OFF
SET LONG 9000000
SET LONGC 900
SET LINES 400
SET TRIMSPOOL ON
SET PAGES 0
SET FEEDBACK OFF
SET HEAD OFF
SET SQLBLANKLINES OFF
SET SERVEROUTPUT ON
BEGIN
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'PRETTY',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'SQLTERMINATOR',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'SEGMENT_ATTRIBUTES',
FALSE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'STORAGE',
FALSE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'TABLESPACE',
FALSE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'REF_CONSTRAINTS',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'SPECIFICATION',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'BODY',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'CONSTRAINTS',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'STORAGE',
TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform,
'CONSTRAINTS_AS_ALTER',
TRUE);
END;
/
SPOOL '&&3'
BEGIN
FOR i IN (SELECT owner,
object_type,
object_name,
created d
FROM all_objects
WHERE owner = '&&1' AND object_name = '&&2')
LOOP
DBMS_OUTPUT.Put_Line (
DBMS_METADATA.get_ddl (REPLACE (i.object_type, ' ', '_'),
i.object_name,
i.owner));
END LOOP;
END;
/
SPOOL OFF
EXIT
Используется 3 входных параметра:1) Пользователь (схема);
2) Объект;
3) Файл для выгрузки.
Пример запуска:
rlwrap sqlplus -silent=true objectman@XE/objectman @/home/maksim/projects/AntOraDDL/GenDDL.sql OBJECTMAN MYBOOKS /home/maksim/projects/AntOraDDL/mybooks.sql
воскресенье, 4 марта 2012 г.
Автодополнение в sqlplus
Наконец нашел то, чего так не хватало в sqlplus'е - простой GPL'ный фрон енд - gqlplus:
- Навигация по истории команд;
- Редактор командной строки (правда все это есть в rlwrap);
- Автододополнении для имен таблиц и колонок (вот это действительно здорово).
Плюс ко всему этому имеются собранные deb и rpm пакеты.
- Навигация по истории команд;
- Редактор командной строки (правда все это есть в rlwrap);
- Автододополнении для имен таблиц и колонок (вот это действительно здорово).
Плюс ко всему этому имеются собранные deb и rpm пакеты.
Подписаться на:
Сообщения (Atom)