Дружище, надеюсь мое мнение не испортило вам самооценку. Как и в любой работе, в it очень важны грамотные руководители, которые не гнушаются грязной работы в прямом и переносном смысле, потому что руководитель не может сказать, что его что-то не касается, даже если он чего-то не знает. Желаю вам успехов в работе )
мой пример:
1. определить SHA коммита, из которого нужны файлы и делаем:
2.
git diff-tree -r --no-commit-id --name-only --diff-filter=ACMRT fd720ceac0b856995afc02921de1615197e9eb0d | xargs tar -rf mytarfile.tar
Смотря что у вас за БД. Можно посоветовать частично хранить и накапливать данные в сессии, а при удобном случае скидывать их в базу (не очень часто). Вроде в php есть fork процесса. Но лучше подумать над логикой приложения, раз всё так завязано на базу и тормозит.
DevMan: Ну тут дело привычки. Понимаю, что прочитав эту инструкцию, вы для себя её, конечно, сократите, но если другой человек первый раз видит эту систему, даже если знает все компоненты, то будут вопросы. Для нормальной работы система должна быть хорошо документирована и изменения в ней должны быть залогированы хотя бы словами. Трудно рассуждать на тему хороша ли или плоха из-за длины и распространённости отдельно взятая инструкция. По-идее хорошо бы был в конторе человек, который принимает или нет такие инструкции к употреблению, но если эта инструкция помогает получить результат, не задавая вопросов разработчику - то это отличная инструкция. Я, конечно, несколько отклонился от основной темы )
Вообще во многих крупных IDE refactor прилагается. Visual Studio, Eclipse отлично с этим справляются. Eclipse немного с JS бывает не понимает, особенно, когда много локальных контекстов, но вот java переваривает на пятёрку.
Можно, конечно и меньше, но, подумайте, что вы даёте такую инструкцию другому человеку поэтому тут избыточность может быть полезна. Т.к. не у всех совпадает мнение относительно длинных "цепочек".
xuxubla: Честно говоря я бы не хотел с таким функционал связываться. Всё-таки 21 век уже давно начался и в объёмах недостатка нет. Если CSV не жалко, то лучше его генерировать заново каждый раз. Но если у вас дамп изменений не совпадает с данными в CSV, то можно сначала загружать его в память, там применить изменения и выложить обратно на диск. У вас скорее всего этот процесс не одномоментный и вы выполняете его не часто за день.
xuxubla: Id - есть. Чтобы сократить затраты на перезапись и не перезаписывать весь файл - рекомендую немного преобразовать CSV - добавить дополнительные пробелы в полях (скажем - 10 дополнительных пробелов изначально), тогда при изменении размеров значений (в пределах допустимого количества символов) - можно перезаписывать строки по одной.
Например:
Сейчас:
1; 121hggh;Table; 2300
Сделать:
1; 121hggh;Table; 2300======
= - пробел.
Понятно, что если изменение текстовых полей больше свободных пробелов, то нужно перезаписывать весь файл от точки изменения, но если будут меняться только цифры, то заложение дополнительных пробелом в вашем случае может хватить.
Быстрое, не значит лучшее, особенно при импорте. Данные надо беречь! Я бы сделал так - сначала залил данные, которые есть в другую, а лучше совсем новую таблицу (с пустым столбцом для дополнительного поля), потом сделал цикл перебора по непустым записям и сохранением значения этого поля. Если будет сбой, то цикл легко начать сначала не боясь повредить уже загруженные данные. Когда всё загрузиться, выполнить загрузку полученной таблицы в целевую таблицу.
Если там разработка не основной профиль, то со сроками сильно могут и не дрючить. А если профиль основной, то очень даже могут (но это в будущем). А так, раз пригласили, значит уже понравился. Это всегда приятно. Если пока вариантов нет, можно и согласиться. Стажировка ведь не сильно обязывает, если что.
