<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
(0) По моему версионник должен ПОМОГАТЬ в работе и навигации по коду. Но случае с 1С, использование того же GIT, похоже на какое то извращение.
Коммит должен быть мгновенным в идеале. Следуя же вашей методологии — коммит превращается в долговременный геморой.
В 8.3 1С существенно оптимизировало работу с хранилищем, и стало возможно работать абсолютно без тормозов с большими конфигурациями (в т.ч. через интернет).
Теперь операции по захвату, отмене, просмотру и публикации происходят почти мгновенно.
По моему для 1С — самое то. Ведь мы имеем дело как с модулями, так и с описанием базы данных (реквизиты, галочки, владельцы и т.д.).
Если модуля можно со скрипом объединять на автомате, то с настройкой прикладных объектов — самое безопасное средство именно монопольный захват на мой взгляд.
Не говоря уже о том, что не нужно ничего устанавливать, допиливать и прикручивать. Все работает из коробки и силами платформы.
Сам активно использую GIT (когда пишу на DELPHI)
Сервер на базе (Gitblit, маленький шустренький, с веб интерфейсом и не требует JAVA)
Выборочная по крайней мере выгрузка скорее всего будет 🙂
Жень, а нет случайно параллельного ведения в одном хранилище нескольких версий конфигурации как отдельных ветотк?
Т.е. конфигурация-родитель и своя на ее основе.
У меня такая схема очень прижилась с бухгалтерией. Есть 2 ветки и в любой момент можно сравнить любую версию родительской с любой версией своей.
С УТ11 схема не работает. После нескольких сотен коммитов на сравнении веток гит просто умирает. GitEntensions еще как-то шевелится, Atlassian зависает намертво.
Подскажи, какую-то идею, как удобно сравнивать различные версии разных схожих конфигураций.
(1) т.к. сейчас метаданные выгружаются в нормальный формат(не считая толстых форм и activex объектов) при небольшом изменении стандартный merge тоже справляется и для форм, и для ролей и для описания объектов метаданных. К сожалению в хранилище упустили момент захвата отдельно «Модуля формы, модуля объекта, модуля менеджера» , а эти объекты могут так-же независимо дорабатываться.
У меня разница между помещением в хранилище и обновлением коммита в git от 10-15 минут, при этом полностью автоматизированно (можно вспомнить фразу «почему не работаете? Так компилиться.» Сейчас с выходом eclipse , 1с тоже пошла путем «быстрый коммит», но теперь обратная сторона долгий деплой. Когда добавят частичную выгрузку по подсистемам, думаю время коммита и разворачивания сравняются.
Проверка на уровне хранилища, нужна, но так же нужна и автоматизированная проверка конфигураци, которая при каждом помещении в хранилище прогонит тестами новый cf файл — я выбрал для себя автоматизированную проверку.
p.s.: я не запрещая пользоваться, я даже советую «пользуйтесь любой системой контроля версий, прошу пользуйтесь», но хранилищем не воспользуешься для внешних обработок и уже надо искать альтернативы.
p.s.s: на момент выступления, gitlab только поднимался и его установка была не тривиальна, а scm manager поддерживает из коробки как git, так и svn, hg…
(3) я у себя так использую.
Все конфигурации которые у меня поставлены на поддержку находятся в отдельных ветках, т.е.:
origin_ut23
origin_bsp
origin_IR
origin_UOS
origin_agentplus
с префиксом origin у меня все типовые которые есть на поддержке в итоговой конфигурации, базовая ut23, все остальные создавалась ветка или же добавлялось как remote репозитарий и делался merge.
Так же использую ветки develop и еще 3 ветки от master на основе которых создаются свои отдельные поставки, т.е. по факту долгоиграющих веток у меня 10 в одном git репозитарии.
(origin_ut23, origin_bsp, …) —> develop —> master , а master распадается на поставки(ветки) develop_simferopol, develop_dnepr, develop_kirovograv .
В принципе тормозов сильных не замечал, переодически делаю git gc, но у меня всего 15 000 объектов при выгрузки конфигурации.
(3) надеюсь, у тебя по каталогам же конфигурация раскидана, а не в линейном виде?
(6) У меня в бухгалтерии было 4 отдельные конфигурации как ветки. Работало отлично.
Сейчас с УТ плохо получается. Внутри веток сравнение нормально работает. Между ветками неприемлемо медленно.
Структура дувхуровневая. Часть по первой точки — папка, внутри файлы.
(5) Кстати, а ветки идут полностью независимо или периодически пересекаются?
С учетом того, что Гит хранит только различия, теоретически это может помочь в сопоставлении файлов веток.
Я вообще не совсем понимаю, как сейчас Гит сравнивает ветки, если они пересекаются только у корня.
Технически для их сравнения необходимо применить всю историю изменений с самого начала для обоих веток и лишь потом их можно будет сравнить между собой.
(8) как мнимум БСП у меня не пересекается, остальные периодически пересекаются, но бывает на 200-500 коммитов могут отличатся. С другой стороны linux kernel спокойно такие diff показывает, т.е. имхо проблема не в этом.
(7) т.е. Catalog.апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt у тебя превращается в Catalog/апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt ? Но тогда это не сильно отличается от линейной структуры….
(9) Да, структура такая.
Вроде хватает для ориентирования по объектам.
Думаешь, может влиять на скорость работы?
(10) как вариант, я пока не знаю где та граница когда начинает тормозить на 10 000 файлов в папке или же на 2000 … Все таки при разбивке по двум точкам в одном каталоге будет значительно меньше файлов Catalog/апОтчетыДляМобильныхУстройств/Form.ФормаЭлемента.Form.Module.txt
Может, не придется больше нам так извращаться:
(12) sashocq, Думаю, все те кто дочитал до этой строки, Eclipse не только видели на картинках, но и к Гиту уже подключали.
На самом деле среда не важна.
Что конфигуратор, что отдельная среда разработки.
Будет все то же самое, что в публикации, только не скриптами и обработками, а Джава-плагинами под Eclipse.
Т.е. публикация больше не о конкретной реализации, а о подходе.
(0) для тех кто хочет прочувствовать как это было — в статью все же нужно добавлять еще и ссылку на открытое видео
На моем сервере типовая БП 3,0 раскладывается на исходники минут 30. Поэтому использовать все эти прелести децентрализованных cvs приходится только как дублирующее хранение исходников конфигурации, где можно быстро посмотреть изменения в самих модулях и их авторство. Для git-flow такое время не приемлемо. (пользуясь случаем, передаю привет Алексею Л. 😉 )
Пять копеек: CVS и SVN хоть и централизованные, но блокировщиками не являются. Они просто поддерживают данный функционал.
(4)
Я начал использовать типовое хранилище для обработок юнит-тестирования. Приходится только добавлять «пустые» объекты, чтобы типизация реквизитов не слетала, и общие модули с пустыми процедурами/функциями, чтобы проходила расширенная проверка конфигурации. Не супер, конечно, но хотя бы что-то.
Прочитал публикацию и для себя определил, что она скорее для расширения кругозора. На практике удобства в моём конкретном случае не представляю.
Возможно потому что конфигурации, которые сопровождаю, находятся на разных серверах в разных частях города и связи между ними как таковой нет (несколько УППэх, несколько КАшек и по мелочи БП/УТ).
Если бы кто-нибудь поделился гениальными идеями как собрать мой огород в одну кучу — был бы только рад.
А пока для себя ничего лучше, чем грамотное оформление кода не придумал 🙂
(18) ИНТЕГРА, не понял вопроса. Чего хотите в итоге добиться? Улучшение качества кода? Уменьшения fail-ов после обновления рабочей базы? Управления кодом (codereview, анализ где,кто и что добавил, по каким задачам был изменено тот или иной участок кода)?
(19) Инкапсулировать все свои доработки/наработки в одном месте, но если у Вас есть конкретное предложение, То почему отвечаете вопросом на вопрос? 🙂
видел, что в 8.3.7.1759 и 8.3.8.1652 уже добавили такую фичу, но мы сидим на 8.3.6 и пока обновиться нет возможности.
если можно, прикрепите обработку к публикации
(21) roofless, все есть
пишут в заголовке темы, что альтернатива есть, а в комментариях — нет. где правда?
(23) правды нет. Есть гит, есть тема про гит на предстоящем евенте, есть релиз едт финальный, для расширений только выгрузка в исходники без хранилища.
Приступая к чтению статьи догадывался что GIT выйдет победителем, и не ошибся.
Скорей всего не один я такой, спасибо что сделали обзор, про другие системы контроля версий ничего не знал.