From: Robbie A. <ra...@ci...> - 2001-05-10 23:57:55
|
Which entry are you talking about in 52-mod.ldif that failed test 47? I'll send out the changes to write soon. I'm also going to add an eof() method so we can use that to test for completion of reading the file instead of read_entry (which can return undef). Robbie Allen > -----Original Message----- > From: Graham Barr [mailto:gb...@po...] > Sent: Wednesday, May 09, 2001 5:44 PM > To: Robbie Allen; per...@li... > Subject: Re: FW: Net::LDAP::LDIF > > > OK, so this was down to bad test data. > > The input LDIF for doing the modify had an entry which did > not have a changetype: modify > line. Adding this in and the tests pass. > > However the new code probably should have flagged a syntax > error instead of what it > did. > > Anyway the code looks good to me, so feel free to make > similar changes to write > > Graham. > > On Thu, May 10, 2001 at 01:12:27AM +0100, Graham Barr wrote: > > Well it seems it is not 100% compatable. > > > > $ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test > > > > t/00ldif-entry......ok > > t/01canon_dn........ok > > t/02filter..........ok > > t/50populate........ok > > t/51search..........ok > > t/52modify..........FAILED tests 47, 56 > > Failed 2/56 tests, 96.43% okay > > t/53schema..........ok > > Failed Test Status Wstat Total Fail Failed List of failed > > > -------------------------------------------------------------- > ----------------- > > t/52modify.t 56 2 3.57% 47, 56 > > Failed 1/7 test scripts, 85.71% okay. 2/347 subtests > failed, 99.42% okay. > > *** Error code 2 > > > > I have not looked closly yet as it is getting late > > > > Graham. > > > > > > On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote: > > > At first glance it looks OK to me. > > > > > > Graham. > > > > > > On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote: > > > > 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 > > > > |
From: Robbie A. <ra...@ci...> - 2001-05-12 00:39:32
Attachments:
LDIF.pm.patchv2
|
I've modified the write methods in LDIF.pm. Attached is the patch for all mod's I've made including the previous patch. I got OpenLDAP setup on my workstation, and LDIF.pm passed all the tests except for 47 and 56, which was the case before my latest mods. To have a unified write_entry() method, I needed a way to distinguish when someone wants to print out an $entry versus printing an $entry with a changetype. To do the latter, I'm requiring the user specify change => 1 when calling new(). I've made the write() and write_cmd() methods backward compatible using the new write_entry() method and setting $self->{change} appropriately. I've also added an eof() method. As I mentioned earlier, you used to have to do: $ldif = Net::LDAP::LDIF->new( "file.ldif", "r" ); while( $entry = $ldif->read_entry() ) { # Do things with $entry } $ldif->done(); The problem is read_entry can return undef on errors. So instead of requiring the while loop to also check for $ldif->error, I added and $ldif->eof method. Now the above example would be written like this: $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror => 'undef' ); while( not $ldif->eof ) { if ($entry = $ldif->read_entry) { # Do things with $entry } else { print "Error msg:\n",$ldif->error(),"\n"; print "Error entry:\n",$ldif->error_entry(),"\n"; } } $ldif->done(); If the changes are acceptable, I'll also modify LDIF.pod to include the new syntax along with write_entry() examples. Robbie Allen > -----Original Message----- > From: Robbie Allen [mailto:ra...@ci...] > Sent: Thursday, May 10, 2001 4:58 PM > To: 'Graham Barr' > Cc: per...@li... > Subject: RE: FW: Net::LDAP::LDIF > > > Which entry are you talking about in 52-mod.ldif that failed test 47? > > I'll send out the changes to write soon. I'm also going to > add an eof() > method so we can use that to test for completion of reading > the file instead > of read_entry (which can return undef). > > Robbie Allen > > > -----Original Message----- > > From: Graham Barr [mailto:gb...@po...] > > Sent: Wednesday, May 09, 2001 5:44 PM > > To: Robbie Allen; per...@li... > > Subject: Re: FW: Net::LDAP::LDIF > > > > > > OK, so this was down to bad test data. > > > > The input LDIF for doing the modify had an entry which did > > not have a changetype: modify > > line. Adding this in and the tests pass. > > > > However the new code probably should have flagged a syntax > > error instead of what it > > did. > > > > Anyway the code looks good to me, so feel free to make > > similar changes to write > > > > Graham. > > > > On Thu, May 10, 2001 at 01:12:27AM +0100, Graham Barr wrote: > > > Well it seems it is not 100% compatable. > > > > > > $ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test > > > > > > t/00ldif-entry......ok > > > t/01canon_dn........ok > > > t/02filter..........ok > > > t/50populate........ok > > > t/51search..........ok > > > t/52modify..........FAILED tests 47, 56 > > > Failed 2/56 tests, 96.43% okay > > > t/53schema..........ok > > > Failed Test Status Wstat Total Fail Failed List of failed > > > > > -------------------------------------------------------------- > > ----------------- > > > t/52modify.t 56 2 3.57% 47, 56 > > > Failed 1/7 test scripts, 85.71% okay. 2/347 subtests > > failed, 99.42% okay. > > > *** Error code 2 > > > > > > I have not looked closly yet as it is getting late > > > > > > Graham. > > > > > > > > > On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote: > > > > At first glance it looks OK to me. > > > > > > > > Graham. > > > > > > > > On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote: > > > > > 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 > > > > > > > |
From: Graham B. <gb...@po...> - 2001-05-12 07:34:38
|
On Fri, May 11, 2001 at 05:39:22PM -0700, Robbie Allen wrote: > If the changes are acceptable, I'll also modify LDIF.pod to include the new > syntax along with write_entry() examples. Looks good to me, except the default for onerror should be undef IMO. Excellent, Thanks, Graham. |
From: Robbie A. <ra...@ci...> - 2001-05-15 17:32:47
Attachments:
LDIF.pm.patch
LDIF.pod.patch
|
Attached is a final patch to LDIF.pm and a patch for LDIF.pod Robbe Allen > -----Original Message----- > From: Graham Barr [mailto:gb...@po...] > Sent: Saturday, May 12, 2001 12:34 AM > To: Robbie Allen > Cc: per...@li... > Subject: Re: FW: Net::LDAP::LDIF > > > On Fri, May 11, 2001 at 05:39:22PM -0700, Robbie Allen wrote: > > > If the changes are acceptable, I'll also modify LDIF.pod to > include the new > > syntax along with write_entry() examples. > > Looks good to me, except the default for onerror should be undef IMO. > > Excellent, Thanks, > Graham. > |
From: Graham B. <gb...@po...> - 2001-05-15 18:19:10
|
On Tue, May 15, 2001 at 10:32:29AM -0700, Robbie Allen wrote: > Attached is a final patch to LDIF.pm and a patch for LDIF.pod Excellent, Thanks. I will apply this tonight Graham. |
From: Graham B. <gb...@po...> - 2001-05-12 07:30:06
Attachments:
52-mod.ldif.pat
|
On Thu, May 10, 2001 at 04:57:44PM -0700, Robbie Allen wrote: > Which entry are you talking about in 52-mod.ldif that failed test 47? > > I'll send out the changes to write soon. I'm also going to add an eof() > method so we can use that to test for completion of reading the file instead > of read_entry (which can return undef). Patch attached. |