Я не могу проверить это, но запросы LDAP используют нотацию , в то время как мы используем infix нотацию. Представьте, что вам нужно что-то, что собака или кошка . В нотации infix это будет выглядеть примерно так:
((ANIMAL = "cat") OR (ANIMAL = "dog"))
С префиксом логический оператор идет в начало запроса:
(OR (ANIMAL = "cat") (ANIMAL = "dog"))
Преимущество с префиксом обозначения появляется, когда вы делаете более двух проверок на логическое значение. Здесь я ищу что-то вроде кошка , собака или вомбат :
(OR (ANIMAL = "cat") (ANIMAL = "dog") (ANIMAL = "wombat"))
Обратите внимание, что мне нужен был только один логический оператор в начале моего оператора. Это ИЛИ объединит все три утверждения. С нашей стандартной нотацией infix мне понадобится второй оператор ИЛИ :
((ANIMAL = "cat") OR (ANIMAL = "dog") OR (ANIMAL = "wombat"))
Префикс нотация была создана польским математиком Яном Лукасевичем еще в 1924 году в Варшавском университете и стала известна как Польская запись . Позже было обнаружено, что компьютеры могут работать с уравнением спереди назад, если уравнение было записано в записи postfix , которая является обратной польской записи. Таким образом, Реверс Польская запись (или RPN) родился.
Ранние калькуляторы HP использовали нотацию RPN , которая стала вещью Geek Sheik еще в начале 1970-х годов. Представьте себе чувство превосходства над мозгом, которое вы получаете, передавая кому-то свой калькулятор, и они не имеют ни малейшего представления, как его использовать. Единственный способ быть круче тогда - это иметь Curta .
Ладно, хватит ходить по ностальгии. Давайте вернемся к проблеме ...
Самый простой способ построить операцию infix - это построить древовидную диаграмму того, что вы хотите. Таким образом, вы должны набросать ваш запрос LDAP в виде дерева:
AND
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
OR employee!=9* mail=*
/ \
/ \
/ \
/ \
/ \
phyDelOfficeName=100 phyDelOfficeName=274
Чтобы построить запрос на основе этого дерева, начните с нижней части дерева и продвигайтесь вверх по каждому слою. Нижняя часть нашего дерева - это ИЛИ часть нашего запроса:
(OR (physicalDeliveryOfficeName = 100) (physicalDeliveryOfficeName = 274))
Используя оператор LDAP ИЛИ , канал (|) и удаляя лишние пробелы, мы получаем:
(|(physicalDeliveryOfficeName = 100)(physicalDeliveryOfficeName = 274))
Когда я создаю запрос LDAP, мне нравится сохранять каждый раздел как скалярную переменную Perl. Это немного облегчает использование:
$or_part = "|(physicalDeliveryOfficeName=100)(physicalDeliveryOfficeName=274)";
Обратите внимание, что я пропустил внешнюю пару или скобки. Внешний набор скобок возвращается, когда вы объединяете все запросы вместе. Тем не менее, некоторые люди ставят их в любом случае. Дополнительный набор скобок не повредит запросу LDAP.
Теперь для двух других частей запроса:
$mailAddrExists = "mail=*";
$not_emp_starts_9 = "!(employee=9*)";
И, теперь мы И все три раздела вместе:
"(&($mailAddrExists)($not_emp_starts_9)($or_part))"
Обратите внимание, что один амперсанд сплетает все вместе. Я могу заменить каждый раздел обратно, чтобы увидеть полный запрос:
(&(mail=*)(!(employee=9*))(|(physicalDeliveryOfficeName=100)(physicalDeliveryOfficeName=274)))
Или вот так:
my $psearch-$ldap->search(
base => $my_base,
attr => ["mail","employeeNumber","physicalDeliveryOfficeName"],
filter => "(&(mail=*)(!(employee=9*))(|(physicalDeliveryOfficeName=100)(physicalDeliveryOfficeName=274)))",
);
Или по частям:
my $mail = "mail=*";
my $employee = "!(employee=9*)";
my $physicalAddress = "|(physicalDeliveryOfficeName=100)"
. "(physicalDeliveryOfficeName=274)";
my $psearch-$ldap->search(
base => $my_base,
attr => ["mail","employeeNumber","physicalDeliveryOfficeName"],
filter => "(&($mail)($employee)($physicalAddress))",
);
Как я уже говорил, я не могу это проверить. Надеюсь это работает. Если ничего другого, я надеюсь, что вы понимаете, как создать запрос LDAP, и можете понять, как сделать это самостоятельно.