В примере в заметке это делается через транзакцию, следовательно с блокировкой, что может быть плохо, если данных уж совсем вагон и все очень долго, но целостность в таком случае не страдает.
Ваше решение хорошее и рабочее и более того, но методологии LEAN, даже более правильное, если это разовая или достаточно редкая операция. Но если это часть бизнес-логики, то уже не такое удобное и надежное, так как уже есть точки интеграции, которые могут сломаться в любой момент времени.
А я тут каким боком к компании выше, или к 1С? Претензии, пожалуйста, им высказываейте, я с этими инструментами вовсе не работаю, но задаю вам конкретный вопрос, как это следует считать? С ваших слов всё просто, так опишите идеальный подход. Мне в самом деле любопытно.
Кроме предвзятой критики у вас ничего по существу вопроса. Так как вы предлагаете гонять на лету литры в килограмы и наоборот? Или вы прям хотите, чтобы на балансе было в кило, а списывалось в литрах? Так пока заливать будут, пару кило успеет испариться в атмосферу, их на потери списывать, или как?
Это не решение, это естественное развитие событий. С тех пор как evo стала форком, осталась одна версия MODX. Следовательно название само по себе сократилось до MODX, так как отпала необходимость уточнять. Кеши гугла весьма умные механизмы и проблема больше надумана, чем есть на самом деле.
Про маразм совсем непонятно, что вы имеете ввиду.
Грузить бигдата целиком в память — ну такое себе решение. Это сейчас 400 мегабайт, а если данных на пару гигов? Срипт даже не запустится. Выше верно подсказали про стримы, а там уже можно и все остальное наворачивать.
Видимо потому что два выпуска в 2016 году канули в лету. Я и рад бы следить за всем, но это невозможно в принципе, особенно за тем, что было 3 года назад.
Критика хорошо, но пока похоже на хейтерство.
zfort больше не спонсирует php-дайджесты, Роман их постит из своего аккаунта, ну и он сейчас в jetbrains, так что косвенные спонсоры они. Заслать пару ссылок туда — идея хорошая и в целом актуальная, но делать это имеет смысл точечно по важным событиям, а свой дайджест тоже хорошо иметь, чтобы быть в курсе новостей, пускай и не таких глобальных.
Заметка писалась относительно давно, поэтому местами код несколько подустарел, возможно, однако важна скорее сама суть подхода, которую я старался донести этой заметкой.
Подход с использованием паттерна object-value хорош, но только когда существует нормальная доменная модель. Заменять бездумно все многомерные массивы классами везде подряд, имхо, неоправданно. Многомерный массив может быть прекрасным наглядным примером, отражающим сразу и структуру данных и ее содержимое. Да, злоупотребрять не нужно, но и кардинально переписывать все на классы (так можно и заболеть ООП головного мозга) тоже не нужно. Самый правильный подход по моему мнению – максимальная простота и читаемость кода. Если массив улучшает понимание кода – он там должен быть.
Из заметки не очень понятно. Правильно ли я понимаю, что R&C поднять карму может только одним способом — написав заметку в песочницу? Для новых пользователей логично, а как это будет работать в случае, когда был полноценный аккаунт, но по различным причинам был переведен в readonly (сейчас R&C)?
вообще не использую, за редким исключением вроде картинок для макета. где-то 100 мб может и нужно, но имхо — это перебор. Это я бы сказал звоночек, что что-то в проекте идет не так, как надо. Ну или повод задуматься об оптимизации или улучшении
Про маразм совсем непонятно, что вы имеете ввиду.
Классы сущностей тут github.com/oat-sa/generis/tree/master/core/kernel/classes
Реализация хранилища тут github.com/oat-sa/generis/tree/master/core/kernel/persistence/smoothsql
Предупреждаю заранее всех, решит возмутиться увиденному, код древнее мамонтов, но так как он ядро всего, туда не спешат лезть руками.
Критика хорошо, но пока похоже на хейтерство.