Вот и я про такие вот «заметки к коду». Понятно что фичи, техдолг все это описывается отдельно, на это выделяется время. А когда знаешь, что работы много-много и чтобы не забыть какие-то вещи вставляешь для себя такие вот «напоминания». Просто одни напоминания важнее других.
Ну по сути надо сделать нормальную постраничку «Последние фотки пользователей». Причем это не обязательно будут фотки. Блогозаписи, метки, видео. Формат хранения — вот такой. С MySQL все просто, сделали count(*) от джойна таблиц и выбрали сколько надо и откуда надо. Хочется сделать максимально прозрачный подход к формированию таких списков. И как мне кажется map/reduce он именно для этого и создан (для порядка назову цифры: пользователей — около 200 тыс, фотки есть у тысячи).
Если делать именно через sort по дате, то в первом документе могут оказаться фотки, которые должны идти последними в списке. То есть на клиенте обработать несколько тысяч фоток для построения списка это нереально. Сервер по идее с этим должен лучше справляться?
Есть конечно вариант построения некого промежуточного звена. Но тогда вообще теряется смысл монго как документ-ориентированного хранилища.
Про aggregation я и писал, мне это показалось клевым, после непонятного map/reduce. Может вы сможете на примере показать как хотя бы подступиться через map/reduce к этой штуке. Это нужно сейчас, подождать новую версию никак не получится.
Подтверждаю проблемность павилионов. У меня куплен полгода назад. Два гарантийных ремонта где-то на полтора месяца: замена шлейфа матрицы и что-то с охлаждением мамки.
Хм, так вроде бы от self отказались в сторону static.
Вот вы говорите о «контексте». И основная ваша мысль в том, что при вызове через static именно меняется контекст объекта, то есть он уже превращается в предка. Так?
Просто это никак не проверить, ибо в php я вот сейчас и не вспомню такую функцию, что бы можно было опознать этот самый контекст. В случае не статических вызовов можно было бы сделать var_dump($this), а тут я тогда не знаю как это проверить.
А товарищ в цитате говорит о том, что static-вызовы не следуют именно «правилам наследования». А каким конкретно не уточняет.
Это не костыль, это все есть реализация идеи LSB. То есть статические методы/поля с учетом этой фишки ведут себя по-другому, а не так как раньше при помощи self.
А что касаемо объема — логично что бы записи хватало на сутки. Я считаю это минимум. Вот у меня КАРКАМ и карточка на 32 Гб — 8 часов видео с одной камеры. То есть для двух камер надо как минимум 200 Гб. Поэтому я и говорю о том, что цена слишком уж. Винты дешевле.
Если не сложно — попробуйте выразить мысль в коде. Ведь по идее наследованию все равно сколько уровней, и если есть пример на три, то вполне может существовать пример на два уровня наследования.
То есть как я понимаю эту фразу — существует такая ситуация, когда static:: не будет являться прямым аналогом this. И поведение наследования будет нелогично.
Так все логично, метод не определен. Значит вызываем родителя. Никакой смены контекста. Просто вызываем метод, а уж метод оперирует своими данными. Переписал этот метод при помощи вызовов this, а не static. Аналогичные результаты. Так и должно быть.
Константа __CLASS__ не показатель, она содержит класс, в котором используется.
