Thread: FW: Net::LDAP::LDIF

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Attached is a patch for LDIF.pm incorporating error handling using an
onerror parameter in new() (just like in LDAP.pm) and a new read_entry()
method.  read_entry() takes the place of read() and read_cmd() making both
of those methods deprecated.  They will be removed in a future version.

Graham, let me know if I'm on the right track.  If so I'll work on the write
methods next.

Robbie Allen

> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]
> Sent: Wednesday, May 09, 2001 12:49 AM
> To: Robbie Allen
> Cc: 'Chris Ridd'
> Subject: Re: Net::LDAP::LDIF
> 
> 
> On Wed, May 09, 2001 at 12:40:43AM -0700, Robbie Allen wrote:
> > Thanks.  Couple more questions.  BTW, if you'd rather I 
> move this to the perl-ldap list, just let me know.
> 
> Yes please.
> 
> > What was the reasoning for the 'changetype' and 'modify' 
> instance variables
> > defined in new()?  Is it so if you have an ldif file full 
> of entries with no
> > commands, that it could default to adding them all when 
> calling read_cmd?
> > It doesn't seem like it would work like that anyway given 
> the current code.
> > Do you want that behavior in the new code?
> 
> It's so that when an entry is read from a server it's 
> changetype defaults to modify.
> 
> Graham.
> 
> > 
> > Robbie Allen
> > 
> > > -----Original Message-----
> > > From: Graham Barr [mailto:gb...@po...]
> > > Sent: Wednesday, May 09, 2001 12:18 AM
> > > To: Robbie Allen
> > > Cc: 'Chris Ridd'
> > > Subject: Re: Net::LDAP::LDIF
> > > 
> > > 
> > > The data directory in the distribution has several.
> > > 
> > > And if you have openldap 1.something you can run the tests by 
> > > first setting
> > > the environment variable SLAPD_EXE to the slapd executeable and
> > > running make test
> > > 
> > > Graham.
> > > 
> > > On Wed, May 09, 2001 at 12:13:52AM -0700, Robbie Allen wrote:
> > > > Do you have any test cases you want me to make sure parses 
> > > correctly?
> > > > 
> > > > Robbie Allen
> > > > 
> > > > > -----Original Message-----
> > > > > From: Graham Barr [mailto:gb...@po...]
> > > > > Sent: Tuesday, May 08, 2001 11:52 PM
> > > > > To: Robbie Allen
> > > > > Cc: 'Chris Ridd'
> > > > > Subject: Re: Net::LDAP::LDIF
> > > > > 
> > > > > 
> > > > > I cannot remember. All I can think of is that the parser 
> > > is different.
> > > > > But we should be able to switch parser when we detect 
> changetype
> > > > > 
> > > > > Graham.
> > > > > 
> > > > > On Tue, May 08, 2001 at 11:23:23PM -0700, Robbie Allen wrote:
> > > > > > Maybe a dumb question, but what was the original 
> > > intent/function of
> > > > > > read_cmd?  Why is it separate from read?
> > > > > > 
> > > > > > Robbie Allen
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Graham Barr [mailto:gb...@po...]
> > > > > > > Sent: Tuesday, May 08, 2001 9:25 AM
> > > > > > > To: Robbie Allen
> > > > > > > Cc: 'Chris Ridd'
> > > > > > > Subject: Re: Net::LDAP::LDIF
> > > > > > > 
> > > > > > > 
> > > > > > > I have been thinking about this a bit more, and here are 
> > > > > my thoughts
> > > > > > > 
> > > > > > > Add a new method called read_entry() which will only read 
> > > > > one entry.
> > > > > > > It should also handle reading normal entries and 
> > > command entries,
> > > > > > > this is something I have been meaning todo.
> > > > > > > 
> > > > > > > Then change read() to call read_entry(), just returning 
> > > > > what it can.
> > > > > > > We then depricate read() (and read_cmd) and 
> remove them later.
> > > > > > > 
> > > > > > > Thought ?
> > > > > > > 
> > > > > > > Graham.
> > > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

> -----Original Message-----
> From: Robbie Allen 
> Sent: Tuesday, May 08, 2001 8:33 AM
> To: 'Graham Barr'; 'Chris Ridd'
> Subject: Net::LDAP::LDIF
> 
> 
> Hi,
> 
> I'm currently modifying Net::LDAP::LDIF to do error handling. 
>  I'm emulating the same onerror behavior as in Net::LDAP.  
> Quick question.  Would it make sense to add an eof() method 
> to LDIF.pm and use that as the marker to determine when the 
> file has been completely read, or should we inform the user 
> that read() may return undef (when errors occur from parsing) 
> which does not necessarily indicate the end of the file?
> 
> From the docs, the example looks like:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r" );
>       while( $entry = $ldif->read() ) {
>               # Do things with $entry
>       }
>       $ldif->done();
> 
> Based on my error handling, I now need to do this:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror 
> => 'undef' );
>       while( $entry = $ldif->read() || $ldif->error() ) {
>           if ($ldif->error()) {
>               print "Error msg:\n",$ldif->error(),"\n";
>               print "Error entry:\n",$ldif->error_entry(),"\n";
>           }
>           else {
>              # Do things with $entry          
>           }
>       }
>       $ldif->done();
> 
> What I'm proposing is a litte more readable I think:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror 
> => 'undef' );
>       while( not $ldif->eof() ) {
>           if ($entry = $ldif->read()) {
>              # Do things with $entry
>           }
>           else {
>               print "Error msg:\n",$ldif->error(),"\n";
>               print "Error entry:\n",$ldif->error_entry(),"\n";
>           }
>       }
>       $ldif->done();
> 
> 
> Then there is still the problem is read() in array context.  
> 
> We could change the docs to:
> 
>      @entries = $ldif->read while not $ldif->eof;
> 
> And get rid of the array context all together.
> 
> Let me know if I'm on the right track.
> 
> Robbie Allen
> 

Thread: FW: Net::LDAP::LDIF

perl-ldap-dev