Можно, конечно и меньше, но, подумайте, что вы даёте такую инструкцию другому человеку поэтому тут избыточность может быть полезна. Т.к. не у всех совпадает мнение относительно длинных "цепочек".
xuxubla: Честно говоря я бы не хотел с таким функционал связываться. Всё-таки 21 век уже давно начался и в объёмах недостатка нет. Если CSV не жалко, то лучше его генерировать заново каждый раз. Но если у вас дамп изменений не совпадает с данными в CSV, то можно сначала загружать его в память, там применить изменения и выложить обратно на диск. У вас скорее всего этот процесс не одномоментный и вы выполняете его не часто за день.
xuxubla: Id - есть. Чтобы сократить затраты на перезапись и не перезаписывать весь файл - рекомендую немного преобразовать CSV - добавить дополнительные пробелы в полях (скажем - 10 дополнительных пробелов изначально), тогда при изменении размеров значений (в пределах допустимого количества символов) - можно перезаписывать строки по одной.
Например:
Сейчас:
1; 121hggh;Table; 2300
Сделать:
1; 121hggh;Table; 2300======
= - пробел.
Понятно, что если изменение текстовых полей больше свободных пробелов, то нужно перезаписывать весь файл от точки изменения, но если будут меняться только цифры, то заложение дополнительных пробелом в вашем случае может хватить.
Быстрое, не значит лучшее, особенно при импорте. Данные надо беречь! Я бы сделал так - сначала залил данные, которые есть в другую, а лучше совсем новую таблицу (с пустым столбцом для дополнительного поля), потом сделал цикл перебора по непустым записям и сохранением значения этого поля. Если будет сбой, то цикл легко начать сначала не боясь повредить уже загруженные данные. Когда всё загрузиться, выполнить загрузку полученной таблицы в целевую таблицу.
Если там разработка не основной профиль, то со сроками сильно могут и не дрючить. А если профиль основной, то очень даже могут (но это в будущем). А так, раз пригласили, значит уже понравился. Это всегда приятно. Если пока вариантов нет, можно и согласиться. Стажировка ведь не сильно обязывает, если что.
конечно, вариант, но др...ть-то когда-то всё равно нужно? Ну и ваш статический вариант наверное был бы правильней, потому что если соединения к стороннему сервису упадут во время импорта - то потом придётся приводить базу в состояние, предшествующее импорту. Это плохо. Но может у Igor это не критично, мы же не знаем )
"$touched/$dirty свойств инпутов": Это не совсем работает, потому что некоторые свойства объекта не имеют отношения к вводу непосредственно. Например, последовательность из организаций, в которых работал пользователь представляет собой массив, поэтому их порядок никак не влияет на сами поля ввода, но изменения порядка уже есть изменения, которые так же надо поймать. Глянул lodash, я правильно понял, что вы имели в виду difference? но там разница только между элементами массива. Он умеет делать что-то с json?
P.S. если есть merge, почему бы не хотеть иметь filter? Это я к тому, что не хотел бы усложнять исходный вопрос. Согласен, вопрос странный, я и сам не сразу его сформулировал для себя.
Конечно. У меня есть достаточно сложная форма заполнения резюме сотрудниками нашей компании. Там может быть не один десяток полей. Когда пользователь производит малейшие манипуляции с формой, то должен выставиться признак модификации (булевский), который визуально превращается в знак (*) в интерфейсе. Я слежу за изменениями с помощью angular $scope.$watchGroup (https://docs.angularjs.org/api/ng/type/$rootScope.Scope) и в него записываю поля, за которыми нужно следить. Количество полей заранее не известно. Вот тут-то и нужен фильтр. Т.к. могут произойти не только изменения в полях ввода, но и ранжирования в массивах данных. Если не пользоваться angular, то нужно вешать самые разные обработки событий на интерфейс. По мне так angular в этом плане хорошо справляется с этой работой.
Ну и вообще, как фундаментальная задачка просто интересна. Я сделал решение, вроде даже простое. Но хочется узнать, нет изобрёл ли я велосипед?
