Skip Menu |

This queue is for tickets about the perl-ldap CPAN distribution.

Report information
The Basics
Id: 45917
Status: rejected
Priority: 0/
Queue: perl-ldap

People
Owner: Nobody in particular
Requestors: dma_k [...] mail.ru
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.39
Fixed in: (no value)



Subject: Empty filter during the search should be acceptable
I would like to make a search knowing only the DN of the record, I would like to find. So I do: $ldap->search('base' => $dn, 'scope' => 'base'); The call dies with message: Bad filter at my.pl line 156 As a workaround I've defined the catch-all filter: $ldap->search('base' => $dn, 'filter' => '(cn=*)', 'scope' => 'base'); I think, this is dummy. search() should accept empty filter and possibly handle this situation somehow internally. At least ldapsearch utility works fine with no filter defined (returns all records).
Subject: Re: [rt.cpan.org #45917] Empty filter during the search should be acceptable
Date: Mon, 11 May 2009 09:28:39 -0500
To: bug-perl-ldap [...] rt.cpan.org
From: Graham Barr <gbarr [...] pobox.com>
On May 10, 2009, at 5:31 AM, dma_k@mail.ru via RT wrote: Show quoted text
> I think, this is dummy. search() should accept empty filter and > possibly > handle this situation somehow internally. At least ldapsearch utility > works fine with no filter defined (returns all records).
Personally I disagree. If the author wants all as a result they should be explicit in their code. The usual search used is '(objectClass=*)'
Show quoted text
> Personally I disagree. If the author wants all as a result they should > be explicit > in their code. The usual search used is '(objectClass=*)'
Well, we have different opinions, that's normal. But for me a framework should be user-oriented, in terms is should be easy and logical. Imagine, that perl precompiler will complain for each uninitialized declaration: my $a; # The variable "a" should be initialized forcing us to write: my $a = undef; # That's fine I would kill myself in a while, really. Sometimes logical assumptions are good :) Anyway, let's vote (in maillist for example)...