Pull to refresh
">alert(document.cookie); @lnromaread⁠-⁠only

">xss

Send message
Я у автора спрашиваю, просто.
Да нет там не глобальная переменная была, там массив передовался в один метод, обрабатывался, возвращался и в другой метод. Где именно, произошла перезапись сложно отследить 'тогда я правда не пользовался xdebug', да и не всегда заметно баг. Да и тут, правильно люди говорят, что массив или объект должны использоваться по ситуации, если система построена на MVC с прослойками абстракции, и там по архитектуре приложения используються объекты, значит мы должны использовать объекты. Если удобно, и это вписываеться в архитектуру, то нужны массивы, если становиться неудобно то нужен объект. В общем всем должен управлять сдравый смысл.
Если это одномерный массив да. Но когда многомерный, и его можно в любом месте, приложения перезаписать $array['test'] = 3 к стати как то я 3 дня искал баг, и как раз из за этого. Если у вас объект вы можете защитить данные разграничить классы которые могут туда записать и т.д. и слёгкостью отследить в какой момент произошла запись вызов сеттера(исли он реализован).
Да не всё нормально в PHP, просто когда на поддержке работаешь, особено после фрилансеров и веб студий, которые клепают сайты под ключ, довольно много непонятного кода. Но это во всех языках "кастыли" пишут и на c++, c, pascal, java, js, php в общем, "кастыли" "языконезависимые".
Боюсь заминусуют но тут:
new StockData("Perch", 50, "2012-02-02 05:23:32")

можно и статическим методом обойтись, зачем каждый раз инстацировать объект, для выполнения одного вычисления?
Вы стараетесь я стараюсь, а начинающие программисты не утруждают себя ставить элементарные скобки, и любят сокращёный синтаксис. Не давно на стэковерфлоу
   if(count=test)
        for(i=0;i<student.length;i++)
            if(student.check)  student.show() && student.showGorod() ;

лиш бы не ставить скобки )
Привидите документацию по этому поводу?
Если посмотреть на zend coding style, то там написано что не следует ипользовать, сокращённый синтаксис. И это не просто так, так как усложняет понимания кода, не всегда явно видно что вот такая строка есть где то в коде $bar = $foo ?? $green;. И потом не всегда понятно от куда $bar = 'red' когда ожидалось $bar = 'green'.
MySql хороша по всем параметрам. Но когда у проэкта возрастает посещаимость и нагрузки. Начинаються проблемы производительностью:
  1. Код который делает перебор разбор данных, рендер и т.д.
  2. Маштабируемость, невозможно на уровне о.с. сделать, так что бы, было несколько серверов с mysql, и какойто сервер балансер который распределял бы запросы по серверам(разграничение нагрузки)
  3. Иногда приложению, не необходимо хранить структуру данных(допусти страницу в cms, понимаю грубый пример но всё же).

Я люблю разделение труда команды, т.е. php программист это один человек, mysql проэктироващик и программист это другой, и третьи лица фронтэнд разработчики. Такая команда добьёться большего результата. Работая в одном направление в месте.
Мне пришлось переписать большую часть приложения для использования PHP7. Плюс не думаю что CMS WordPress будет его поддерживать. Так как в wordpress один большой кастыль. Да и говорить что мы полностью поддерживаем PHP7 в тот момент когда его небыло, как то не вызывает доверия. К сожаления PHP7(точнее расширения к нему) падает с segfault на 2-х машинах и только на одном работает(на домашней машине).
Большинству разработчиков, необходима лишь IDE, терминал(urxvt) и тестовая среда (для веб это браузер к примеру), всеми остальными приложениями удобнее пользоваться в консоли.
Awesome — тайловый менеджер. Но это не окружение рабочего стола.
Я тоже должен извиниться, я только начинаю изучать mongoDB, и нахожу всё больше и больше плюсов по сравнению с sql, может это просто первое впечатление. Ну да ладно, оффтоп, спс за ссылку.
да нет не вся ветка, я в посте не привёл все данные 'сопутствующие' что бы легче читать было, в посте приходит id страницы. Если нет в посте reply производиться insert в монго т.е. комментарий первого уровня, а вот уже реплики на комментарий привязываеться к родителю(т.е. тогда когда есть reply ), по коду к стати довольно хорошо это видно, видимо плохо видно, видимо мой касяк.
именно этот алгоритм я вам и описал, недочитываете до конца или через строку?
По сути есть коментарий_родитель-> (коментарий_потомок, коментарий_потомок) я привёл пример в посте.
Так то храниться отдельно комент и е го потомки в одном документе. т.е. получаеться при выборке коллекция комментариев, в которых есть дочерние элементы.
Да postgresql умеет, но всё же пост не о postgre и не о проблеме построение деревьев а всё же о mongoDB.
P.S. Спасибо!
ok. Вы имеете id | parent_id | comment | name минимальный набор полей как построить дерево. Сделать рекурсию и к каждому корневому коментарию, выбирать с базы parent'ы. Ок, всё выбираеться. Но есть одно но вы сделали кучу запросов и сервер упал на этапе, просто выборки. Алгоритм выполняет много запросов и обрабатывает кучу данных, что не так оптимально. И так вы модернизируете алгоритм вводите понятия level и right_id и left_id что бы одним запросом вытянуть все коментарии, в порядке комент level1-> комент level2 ->комент level1 всё вроде бы просто…
Но вам надо сформировать массив вида comment['parent']->array(comment[]) думаю ясно логика, вы делаете перебор линейного массива и строите, древовидную структуру. Так вот вы взяли данные, выполнили операции перебора этих данных и модификации в массив. В монгоДБ мы просто сохраняем этот массив и просто берём его, тут вы взяли данные и не произвели над ними операций. Какой алгоритм лучше по вашему мнению? Да и видно что вы не строили древовидные структуры?
Мне стыдно (( замечание конструктивное.

Information

Rating
Does not participate
Location
Aggsbach Dorf, Niederösterreich, Австрия
Date of birth
Registered
Activity