denver

Зачем вообще делать хэширование, держать набор на клиенте, если у вас есть первичный ключ?

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

Мне понравился совет из ответа выше сперва проапдейтить признак удаленности. Вернее сначала мне он не понравился, однако как альтернатива загрузки полного набора записей на сторону датабазы с целью последующего вычитания множеств, это может оказаться вполне даже разумным.

spmbt, моё мнение не поменялось — Без ZenComment и Без HabrAjax. Обе реализации плохи в плане цветовой палитры.

Лучше свести всю палитру к 2-3 тонам цвета и использовать различную насыщенность или яркость для выделения элементов.

А в строке содержащей слово city всегда есть слово big?.. Раз уж взялись уточнять, давайте точно описание ситуации. Хотя обычно я прошу кусок исходного файла.

sed '/city/s/\(.*\)/\1 default/' /path/to/your/file
В таком виде sed выведет результат на экран, если хотите изменить исходный файл, то запустите sed с ключём -i (sed -i ...)

дергайте функцию через setInterval

тогда уж
find -mmin -5 -type f -delete


find -mmin -5 -type f -exec rm '{}' \;

лента -> посты

Я решил эту проблему просто.

1. Сделал аккаунт S3 на амазоне
2. Поставил s3cmd из портов
3. Написал скрипт на php для создания инкрементального бекапа и базы… отслеживается двух недельная история архивов, все старые удаляются, при синхронизацией с S3 старые бекапы удаляются также.

messages:
+----+------+
| id | text |
+----+------+

user_messages:
+---------+------------+
| user_id | message_id |
+---------+------------+

Делаете таблицу прочитанных сообщений со структурой user_id & id_уведомления, PK на оба поля.
Показ уведомлений:

select текст from уведомления left join прочитанные_уведомления on id_уведомления=id and user_id=? where user_id is null

И метите уведомления прочитанными созданием таковых записей.

Или можно инвертировать логику — вносить в таблицу id непрочитанных уведомлений и удалять при прочтении.

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

С безопасностью проблем в целом (если с умом подходить к самому скрипту) проблем нет. Ну и за basic auth лучше убрать.
Теги в гугле — apache bash cgi run.

как-то сложные варианты здесь насоветовали. CGI всё правильно, это в ту сторону. Как оно настраивается это придётся прочитать в доках к lighttpd, возможно уже работает.
Кидаете в директорию cgi файл test.cgi с chmod +x
#!/bin/bash
echo "Content-type: text/html" #или text/plain и любое другое
echo ""
echo "<h1>test</h1>"
и открываете в браузере http://site/cgi/test.cgi, если вывелось то всё отлично.
С безопасностью тоже всё прекрасно, не вижу проблем чем shell скрипт отличается от любого другого php, rb, py и т.д.

В этом и прелесть интерфейсов, потом в коде FileDataKeeper будет использоваться только при создании объекта, а сам объект передаваться по типу DataKeeper, т.е.

$keeper = new FileDataKeeper();
$someService->setDataKeeper($keeper);
// or 
$keeper = new MysqlDataKeeper();
$someService->setDataKeeper($keeper);

class SomeService
{
    // ...
    public function setDataKeeper(DataKeeper $keeper)
    {
         // ...
    }
    // ...
}

Кроме того, если я захочу поменять реализацию хранения, заменив класс FileDataKeeper, например, на MySQLDataKeeper, интерфейс и открытые методы-то не изменятся, а вот «new FileDataKeeper» надо будет менять по всему проекту.

en.wikipedia.org/wiki/Dependency_injection

Проблема в ИЕ решается заменой button на input typr=submit. Адекватнее сделать сначала удаление через POST формы, потом, если есть время, добавить аяксовое удаление и восстановление записей (надеюсь, вы уже не делаете confirm('А вы точно нажали на кнопку «Удалить»?')).

можно сделать в форме кучу кнопок типа submit с разными именами, серверу будет передано name нажатой кнопки…

ИМХО, задача реквеста — принять входящие данные (POST/GET/COOKIE и прочие заголовки), инициировать запуск нужного метода контроллера, и вернуть реквест с результатом. Соответственно, вся логика (валидация, запросы к БД и т.д.) должна лежать в контроллере, но не запросе. Request — служебный класс, и его имеет смысл разбивать на подклассы, если возможны различные варианты обработки входящего запроса, но никак не подстраиваться под бизнес-логику.