значит, есть у нас строка

$str = '(A and B) or C';

эта строка пойдёт в запрос:
но предварительно перед подстановкой в ней A, B, C, D и т.д. будут заменены на соответствующие выражения
A => `field1`=2
B => `field2`>5
и так далее

соответственно, надо вначале проверить формат строки, чтобы не было лишних символов, типа (A and + B) 111 or C
чтобы все скобки открывали/закрывались
и что самое важное - выполнялось логическое построение, т.е. не образовывалось хвостов в воздухе (A and ) or C

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

но вот разобраться хотя бы с первыми двумя:
1. чтобы не было лишних символов, типа (A and + B) 111 or C /должны остаться A, B, ... Z, and, or, (, )/
2. чтобы все скобки открывали/закрывались

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

вот. помогите, кто чем может


п.с. в принципе, мне не шибко важно, если бы строка имела вид не (A and B) or C, а (0 and 1) or 2
просто с буковками вменяемей смотрится

нужно любой вариант учесть? 
к примеру

да, любой вариант. в том числе и этот

А такой формат допустим?
A and B and C
?


Если нет, то третья проблема, да и вся задача решается без особых проблем! 

Нужна некая функция, которая будет рекурсивно проверять каждую скобку.
Примерная структура, если писать словами, будет такой


Функция test ($text)
{
    Ругулярка  
    [A-Z] [or|and] [A-Z]
    Если подходит, то возвратить true


    Если не подходит, то проверить
    \((.+)\) [or|and] \((.+)\)
    Если совпадает, то 
    return test (первая скобка) and test (содержимое второй скобки)

    Иначе, если не совпадает, то проверить 
    \((.+)\) [or|and] [A-Z]
    return test (Содержимое скобки)
    
    Иначе, если и это не совпадает, то проверить
    [A-Z] [or|and] \((.+)\)
    return test (Содержимое скобки)    
    
    Иначе
    retuen false
}

Если не понятно, попробую написать

и такой тоже



я уже здесь споткнусь. как отсеять из (AB and C) вот это сочетание - AB?

да, в этом конкретном случае, по сути исправлять наверное особо то ничего и не требуется. достаточно установить, что неправильный формат и выдать false. пущай сам ручками исправляет



кстати, кодировка - utf8


  

Причём тут A, B, ...? Составляйте сразу выражение "(field1 > 5 and field2 = 6) or 1=2" и проверяйте с помощью конечных автоматов (регулярками тут разве что на token'ы разбивать, не более).

Вообще это дикая идея позволить пользователю составлять своё условие?

Это сообщение отредактировал(а) Pitlord - 24.11.2009, 19:00

Ура!!! Заработало!!!
Правда пока только упрощенная версия, которая не позволяет написать A and B and C
Приходится писать A and (B and C),
сейчас еще подумаю, может сварганю полную версию.


Добавлено через 13 минут и 6 секунд
Версия номер 2, позволяет писать любое количество пробелов, там где это допустимо синтаксисом.

не знаю. по-моему проще проверить пока строка не заполнилась апострофами, неизвестными именами полей, знаками = > < , да ещё и служебными словами LIKE, REGEXP и прочее



что есть конечный автомат?



NLspieler, спасибо за труды, попробую завтра потестить

Добавлено через 2 минуты и 49 секунд

есть такие пользователи

в крайнем случае для штурманского (административного) аппарата сгодится

Сам не могу в это поверить, но у меня получилась полная версия, которая полностью выполняет поставленную задачу!

Смысл в том, что функция находит скобки, в которых больше нет скобок.
Проверяет, при помощи вспомогательной функции, все ли там в порядке. 
Проверить Z and Z and Z and Z ... на правильность не составляет особого труда.

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

Скорость обработки представленного мною примера занимает менее половины милисекунды.



Это сообщение отредактировал(а) NLspieler - 25.11.2009, 09:15

Лучше уж(и много проще) тогда просто дать возможность вводить любой запрос с выводом mysql_error.

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

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

и вы при этом носите гордое звание начальника транспортного цеха программиста!

ещё хотел добавить о космических кораблях, бороздящих просторы большого театра, но как-то к слову не пришлось

Если вы гордый носитель звания блондинка,
то вам надо предоставить сторонний интерактивный генератор отчетов у которого много больше рюшечек чем в ваших таблицах, и который выдает отчет в 15ти форматах
Если же вы действительно администратор, то нужна возможность ввода произвольного SQL запроса для создания отчетов (которые буду выполняться другими пользователями-блондинками).

Попытка предположить что вы администратор недоблондинка(а в какой степени - черт его знает) выльется в полгода геморроя при создании очередного собственного велосипеда - генератора отчетов.

Ах, да, естественно что ты не смог догадаться - результат выполнения произвольного SQL запроса может выводиться не в виде дампа, а в виде таблицы с рюшечками, в XML, Excel, или просто PDF-формате.

Ты меня все больше и больше печалишь :( Тебя повысили что ли?

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


эту хренотень я сделал давным давно ещё при написании инструмента для работы с БД. в купе с логированием, выбором БД, разборки ответа и выдачи сообщениями с ошибоками

всего две недели свободного рабочего времени

а вот уже и откровенное оскорбление


если ещё немного подумать, то можно догадаться, что и запрос можно составлять не ввиде чернушного кода, а в табличе с рюшечками. где тебе не придётся размышлять, а что же означают данные поля, подставить в where status=1 или =0? вместо этого, можно просто кликая мышкой выбрать в падающем списке нужный статус (новый/одобрено/корзина) и получить нужную фильтрацию




и хде я упоминал про системы отчёта? опять что-то себе придумал?

отлично, вариант NLspieler выполняет всё как нужно

спасибо

В этом интерфейсе не возникает вопрос подобный твоему.



Вполне очевидно, что у меня длиннее - потребовалось всего 3 дня. 
Но я вполне отдают отчет что это и рядом не стояло с Crystal Reports, Fast Reports etc.


Нормальному админу это бесполезно. Потому что любой функционал который ты можешь написать за две недели - убог.
(я тоже за это время не напишу ничего выдающегося, но это не оправдание для тебя)
А действительно нужный функционал ты не реализовал.


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

Тем не менее...
Вот это

Имеет смысл в двух местах - репортинговой системе или ОРМ. Писать и то и другое - достаточно глупо.
Еще более странно если "это" потребовалось в другом месте приложения.