Имхо, но не никакой разницы, надо вызывать метод save из обертки или из самой модели, но вот проблемы наступают, когда бизнес-логику начинают складывать в модель. И по идее это active record

А в этом какая проблема?

Непонятно почему ты SRP притягиваешь к моделям ORM

Потому что у нас тут спор про active record. И это всё связанно.

Потому что у нас тут спор про active record. И это всё связанно.

модель и её lazy связи уже приводят к тому что ты оперируешь несколькими классами

А в этом какая проблема?

Проблема начинается тогда, когда этой логики становится ОЧЕНЬ много и из-за этого становится практически невозможно проводить юнит тестирование, так как все связано со всем. То есть изоляция между компонентами отсутствует, легко задеть один, изменяя другой и так далее. Я это испытывал на проектах с odoo, когда каждый раз мы упирались в то, что юнит-тестирование практически невозможно, потому что отдельная функция делать ничего и все сразу

И только интеграционка, только очень долгие и сложные тесты

Проблема начинается тогда, когда этой логики становится ОЧЕНЬ много и из-за этого становится практически невозможно проводить юнит тестирование, так как все связано со всем. То есть изоляция между компонентами отсутствует, легко задеть один, изменяя другой и так далее. Я это испытывал на проектах с odoo, когда каждый раз мы упирались в то, что юнит-тестирование практически невозможно, потому что отдельная функция делать ничего и все сразу

Юнит-тестированию все равно, в модели это или отдельно. Оно тестирует логику метода. Если он распух, ты его не протестируешь нигде. Я вот ни разу не сталкивался с тем, что вынос чего-то из модели упрощал тестирование.

Ну и логика разлезается по всем этим актив рекордам, вместо того, что бы быть сконцетрированной в нужных местах

Ну и логика разлезается по всем этим актив рекордам, вместо того, что бы быть сконцетрированной в нужных местах

Если юзер должен активироваться единственно верным способом, куда его засунуть, кроме как в User.activate()

Юнит-тестированию все равно, в модели это или отдельно. Оно тестирует логику метода. Если он распух, ты его не протестируешь нигде. Я вот ни разу не сталкивался с тем, что вынос чего-то из модели упрощал тестирование.

Ну, мой поинт в том что active record провоцирует архитектуру такого типа.

Если юзер должен активироваться единственно верным способом, куда его засунуть, кроме как в User.activate()

UserService.active(user)?

Или ActivationService.active_user(user)?

UserService.active(user)?

А service это что?

Кусок логики, который оперирует сущностью или бизнес-процессом

модель и её lazy связи уже приводят к тому что ты оперируешь несколькими классами

Я не про это. Я больше про то, что модель знает, что она модель что в active record, что в data mapper. И программисту приходится это тоже знать. Так что с одной стороны, active record - это антипаттерн, с другой стороны, многие реализции data mapper как бы оказываются не сильно лучше.

Если он оперирует сущностями, это все же часть модели

Если нет, это часть view, но тогда его придется дублировать

Если он оперирует сущностями, это все же часть модели

Он не отвечает за данные - он часть бизнес-процесса, обычно.

По идее смысл в том, что в модели нужно хранить исключительно логику работы с данными модели - все остальное не должно в ней лежать

Он не отвечает за данные - он часть бизнес-процесса, обычно.

И в чем принципиальное отличие от методов непосредственно модели?

Джанго орм с тобой не соглашается

Например, в том, что для тестирования такого кода вам не нужна модель?

Джанго орм с тобой не соглашается

Хм ... а где? Ну, если что, я отношу работу с бд к работой с данными

Например, в том, что для тестирования такого кода вам не нужна модель?

Ну как не нужна. Чтобы проверить активацию юзера, надо, наверное, создать юзера и посмотреть, что с ним происходит при активации

Хм ... а где? Ну, если что, я отношу работу с бд к работой с данными

В стандартном классе User много разных методов

Ну как не нужна. Чтобы проверить активацию юзера, надо, наверное, создать юзера и посмотреть, что с ним происходит при активации

Туда можно передать мок объект и проверить, что нужные изменения произведены.

В стандартном классе User много разных методов

Эх, жаль, что мы его не используем :)

Создание, проверка паролей, разрешений и всего такого

Туда можно передать мок объект и проверить, что нужные изменения произведены.

Но можно просто создать юзера. Джанга делает тестирование кода, работающего с бд, довольно удобным

Ну, у меня просто отходняк от odoo, где нельзя было просто создать один объект. Нужно было создать их штук 20, с кучей разных данных, правильно заполненный и так далее.

Если надо создавать 20 объектов, то и одного мока не хватит

Если разделить логику, что бы бизнес-операции были атомарны, то это не нужно

Но в active record после какого-то момента это слишком сложно сделать

Но иногда активация юзера хочет еще отправить кому-то уведомление, изменить какую-то статистику и еще много всего. Тут вроде без разницы, каким способом тестировать, все равно будет сложно без моков

Но иногда активация юзера хочет еще отправить кому-то уведомление, изменить какую-то статистику и еще много всего. Тут вроде без разницы, каким способом тестировать, все равно будет сложно без моков

ну в модель не обязательно такую функциональность вносить

Да где бы она ни была, тестирование проще не станет

Подскажите, если я с первого процесса пишу в файл, а с другого процесса хочу проверить, открыл ли ещё этот файл на запись, как я могу сделать это? Обычный open () не выдает никакого ексепшена

Подскажите, если я с первого процесса пишу в файл, а с другого процесса хочу проверить, открыл ли ещё этот файл на запись, как я могу сделать это? Обычный open () не выдает никакого ексепшена

правильно не выдает, и не должен выдавать.

правильно не выдает, и не должен выдавать.

как быть? Даже если я переименновываю его, он мне просто создает новый)

на самом деле надежного способа сделать это не существует. есть файловые блокировки через flock()

на самом деле надежного способа сделать это не существует. есть файловые блокировки через flock()

спасибо, почитаю

гугли по fcntl / flock или exlusive file lock linux

туда же в догонку (при всей моей не любвик к Автору) статья http://0pointer.de/blog/projects/locking.html

Подскажите, если я с первого процесса пишу в файл, а с другого процесса хочу проверить, открыл ли ещё этот файл на запись, как я могу сделать это? Обычный open () не выдает никакого ексепшена

а заяем именно такая последовательность?

то ест ья конечно на локах делал себе локальный кэш файлов, но наверняка для твоего кейса есть решение лучше

а заяем именно такая последовательность?

мне сказали так, решение такое

а тебе для чего это?

Кто нибудь интересовался управлением linux через snmp?

/me не доверяет snmp

там же авторизации толком нет

Здрасте. Подскажите, плиз, какими инструментами можно считать и визуализировать формат .csv через питон?

там же авторизации толком нет

Шифровать еси ток

там же авторизации толком нет

ты хотел сказать аутентификации.

считать через import csv, визуализировать - это как?

ты хотел сказать аутентификации.

ну скорее все таки авторизации. Не слишком безопасно определяется можно давать досутп или нет

считать через import csv, визуализировать - это как?

Визуализировать данные трехмерной матрицы

@vyat1ch будет жить. Поприветствуем!

Визуализировать данные трехмерной матрицы

matplotlib?

а тебе для чего это?

ну есть скрпит который пишет в файлы. Есть другой скрпит,в котором первый процесс считывает названия этих файлов и складывает их названия в очередь. Другой процесс - пишет в базу с них, удаляет файлы. А проверять мне нужно, потому что между первым и и вторым процессом идет обмен СПИСКОМ, и если этот файл уже ждет своего удаления во втором процессе, то первый процесс этого знать не будет и запишет его вновь на отправку во второй процесс. Если он будет видеть, что тот файл открыл - он этого не сделает

почему такая ошибка может происходить? free() invalid next size (normal)

ну есть скрпит который пишет в файлы. Есть другой скрпит,в котором первый процесс считывает названия этих файлов и складывает их названия в очередь. Другой процесс - пишет в базу с них, удаляет файлы. А проверять мне нужно, потому что между первым и и вторым процессом идет обмен СПИСКОМ, и если этот файл уже ждет своего удаления во втором процессе, то первый процесс этого знать не будет и запишет его вновь на отправку во второй процесс. Если он будет видеть, что тот файл открыл - он этого не сделает

так, во-первых зачем тебе это делать на файлах? во-вторых, перед тем как отправлять второму файл на обработку перестань в нег описать. Иначе у тебя 100500 вариантов гонки

ну есть скрпит который пишет в файлы. Есть другой скрпит,в котором первый процесс считывает названия этих файлов и складывает их названия в очередь. Другой процесс - пишет в базу с них, удаляет файлы. А проверять мне нужно, потому что между первым и и вторым процессом идет обмен СПИСКОМ, и если этот файл уже ждет своего удаления во втором процессе, то первый процесс этого знать не будет и запишет его вновь на отправку во второй процесс. Если он будет видеть, что тот файл открыл - он этого не сделает

o_O

так, во-первых зачем тебе это делать на файлах? во-вторых, перед тем как отправлять второму файл на обработку перестань в нег описать. Иначе у тебя 100500 вариантов гонки

перестану. Это как проверка, на всякий случай

считайте это моей философией: если хочешь помочь, вместо того чтобы ответить человеку на вопрос уточни зачем ему это надо. Наверняка он уже делает что-то не то

перестану. Это как проверка, на всякий случай

не должно быт ьвсяких случаев. Код должен работать так, чтобы эти случаи просто не могли возникнуть.

ну я про данный кейс

ну есть скрпит который пишет в файлы. Есть другой скрпит,в котором первый процесс считывает названия этих файлов и складывает их названия в очередь. Другой процесс - пишет в базу с них, удаляет файлы. А проверять мне нужно, потому что между первым и и вторым процессом идет обмен СПИСКОМ, и если этот файл уже ждет своего удаления во втором процессе, то первый процесс этого знать не будет и запишет его вновь на отправку во второй процесс. Если он будет видеть, что тот файл открыл - он этого не сделает

а теперь к вопросу 1. Зачем ты так сделал?

считайте это моей философией: если хочешь помочь, вместо того чтобы ответить человеку на вопрос уточни зачем ему это надо. Наверняка он уже делает что-то не то

xyproblem же

xyproblem же

ну типа

а мне лень докапываться.

=(

а теперь к вопросу 1. Зачем ты так сделал?

мне так сказал человек стоящий "выше". Я всего лишь выполняю таски

когда лень, я не пишу в чат

мне так сказал человек стоящий "выше". Я всего лишь выполняю таски

плохой программист будет бездумно выполнять таски

мне так сказал человек стоящий "выше". Я всего лишь выполняю таски

ну очевидно что стоящий выше возможно некометентен

я не могу оспорить

я пытался

ну либо произошло недопонимание

что тоже возможно

еще с самой начала, когда возникла идея писать в файлы

но, увы)

ладно

а какйо аргумент был?

"это самое простое. Небольшой костылик но будет работать"

вообще в идеале у тебя не должно быть ситуации когда с одним файлом работают > 1 процесса.

на запись

вообще в идеале у тебя не должно быть ситуации когда с одним файлом работают > 1 процесса.

+

"это самое простое. Небольшой костылик но будет работать"

у меня сейчас весь проект из таких "небольших" костыликов состоит

и тут это делается просто

хочется стреляться.

а

вот, посмотрел в код и допишу: скрипт, который пишет в файл может долго держать паузу и поэтому файл моэет быть открымым очень долго

поэтому нужна проверка, открыт ли файл или нет

Не надо так

не могу(

Зачем ты второму скрипту отдаёшь имя файла, если ещё не закрыл?

этот скрипт - это АПИ функция. не будет запроса - функция не вызовится