Это же даже не бета. Это проба концепции я так понимаю.
Уверен, что у него сейчас голова скрипит от продумывания, как что хранить и в каком виде отображать... смотрит на то что получается на экране и скрипит мозгами.
Теперь вы пишете ответ на «#2 Ответ», и ещё вы хотите ответить на «#1 Сообщение», вы упоминаете сообщение >>1 и оно дублируется в оба места, потому что оно является ответом на второй ответ и в нём упоминается первое сообщение.
#1 > Сообщение
#2 > > Ответ
#3 > > > Ответ
#3 > Ответ
ИМХО всё логично. :)
Если вы раскроете тред, то увидите, что всё отображается корректно. Это только дерево так хитро рисуется. =)
Одна единственная таблица для всех сообщений. Структура деревьев рисуется элементарно просто — каждое сообщение это путь, который оно проходит.
Опять же, сообщение 1 и сообщение 2, где 2 является ответом на 1, а сообщение 3 является ответом на сообщение 2.
Путь:
1
1.2
1.2.3
Как вывести все ответы на сообщение 1? Сделать выборку «LIKE 1.%». Один единственный SQL запрос, чтобы нарисовать всё дерево целиком, никакой рекурсии не нужно.
Вся структура ответов на сообщения лежит в thread и multithread колонках. Имеет вид, где каждое сообщение (ID) разделено точкой: 1.2.3.4.5. Так и рисует деревья.
В thread находятся просто прямые ответы на сообщения, а в multithread ещё и ответы на >>циферки.
Просто у тебя там некие поля, пароль и ещё чего-то... оно не должно быть тут (другая таблица однозначно).
Ну а про то, что индексов у тебя нет ни на одном поле... ну это проявится при некоем ощутимом количестве записей и количестве одновременно пишущих/читающих людей.
Про одновременные записи ответов без обработки транзакций, тоже плохо.
Кто первый тот и прав получится... Остальных выбросит с ошибкой 500
Я тебе завидую в том плане, что у тебя получается делать вещи для себя, ориентируясь на свои приоритеты и интересы, а не стандарты окружающих.
Подозреваю что тебе приносит удовольствие читать критиканов - они, конечно, могут написать тоже самое на полдня на джангах, но это просто им не нужно и поэтому им удоволствие сам процесс не принесёт %)
Когда-то и я так мог, когда процесс разработки хомяка с похожим говнокодом делал меня счастливым, но к несчастью я поумнел и стал писать хороший код который мне совсем не нужен, а нужен дяде. И теперь ненавижу компы и предпочитаю больше кататься на велике
щя вот думаю чего б ещё запилить.. файлообменник есть, форум для обратной связи имеется, ЖЖ имеется, конечно это всё надо в порядок привести ещё. но пора начинать пилить какой-то новый проект. :)
За советы всем спасибо, переделал пару моментов — определение mime-типа с использованием file, а конвертация картинок с использованием convert из imagemagick.
Потом сделаю возможность загружать видео и аудио. И возможно какие другие файлы... Короче, обычный файлохостинг с обсуждением получится в итоге. =)
инкрементирую. многие, видимо, уже забыли, как оно - писать JFF. у меня вон тоже, на диске валяется директория, с целой кучей «проектов» разной степени (не)законченности, которую я начал наполнять еще в каких-то мохнатых годах. там и Delphi, и с/с++, и Qt, и Java встречается. правда я не выкладываю все это на gitgub/etc., но это потому, что когда я только начинал что-то писать, всякие VCS еще не были так популярны, вот и не сложилось такой привычки. а вообще, дело видимо в том, что у меня программирование никогда не выходило за рамки хобби.
ps. я даже не стал проверять, экранируется ли имя, потому что подумал, что подобная глупость стала устаревшей ещё в 2003 году... хотя хотел, но глядя код - быстро перехотелось вообще что-то проверять :)
просто подобные ошибки «не на php» допустить в разы сложнее. или используя шаблоны, где неэкранированное не вылезет. и orm, где неэкранированное не влезет
python, как язык, в разы легче :) и это при том, что python я знаю с 2011 (точнее, наверное, с 2012, первый десяток сайтиков на bottle.py я написал, вообще не зная python. не зная в принципе - понятия не имея, как hello, world запустить), а php - с 2002, застал ещё эпоху популярности php3.
Лучше Java тогда. На Си/Си++ утечек ждёшь и поэтому они очевидны. А вот когда память начинает на Java утекать, начинаешь ломать голову, в каком месте по многочисленным цепочкам объектов оно подвисло :)
Да. Я не знаю какие колонки нужно индексировать и почему/зачем. И как обрабатывать так называемые исключительные ситуации при транзакциях. Мне казалось, того что я сделал таймаут побольшое 5000мс и засунул всё это дело в транзакцию — этого уже достаточно. Я выполнил бенчмарком ab 5000 тысяч параллельных запросов по 100 штук за раз, все обработались без ошибок.
Я не знаю какие колонки нужно индексировать и почему/зачем
Обычно индексируют колонки, по которым чаще всего идёт поиск. Ну например поле post_id.
Можно конечно индексировать все, но индексация тоже достаточно тяжёлый процесс и потому, лучше лишний раз не нагружать БД.
Транзакции может и сам контейнер PHP обрабатывает нормально и ставит в очередь. Потому может больше ничего делать и не нужно. Я досконально для ПХП такого не изучал.
Добра тебе, теперь у половины лора настроение поднимется - будут думать, какие они офигенные программисты. Я смотрю, в теме уже многие начали отмечаться.