Re: [Openinteract-help] SPOPS::LDAP _clear not working

[<rlr...@dc...>]

I am still having a problem with the _clear methods in SPOPS::LDAP subclasses.  
The cleared attribute is set to 'undef' rather than being deleted, and calling 
save() on the object passes the attribute to the LDAP server with a null
value.  If objectClass has changed to one that does not allow this attribute, 
the save fails.

This is probably harmless under SPOPS::DBI as your table schemas hopefully do
not change between fetching and saving the user.

Lee

On Tue, Mar 02, 2004 at 11:42:28AM -0500, Lee Revell wrote:
> I ran some more tests, and it seems that this behavior only occurs for 
> attributes fetched from the persistent store.  Once you use the
> automatically generated mutator to change a value then foo_clear works
> as expected: 
> 
> $user = DCA::User->fetch("rlrevell"); print $user->o
> DCANet
> 
> $user = DCA::User->fetch("rlrevell"); $user->o_clear; print $user->o
> DCANet
> 
> $user = DCA::User->fetch("rlrevell"); $user->o("Foo"); print $user->o
> Foo
> 
> $user = DCA::User->fetch("rlrevell"); $user->o("Foo"); $user->o_clear; print $user->o
> <prints nothing>
> 
> Hope this helps,
> 
> Lee
> 
> On Tue, Mar 02, 2004 at 11:03:40AM -0500, Lee Revell wrote:
> > On Tue, Mar 02, 2004 at 07:32:01AM -0500, Chris Winters wrote:
> > > On Mar 1, 2004, at 6:36 PM, Lee Revell wrote:
> > > >I have an SPOPS::LDAP subclass called DCA::User for which the
> > > >automatically generated $FIELD_clear() methods do not seem to
> > > >work.  Here is an example (I have overridden as_string from
> > > >SPOPS to produce LDIF output):
> > > >
> > > >perl -MDCA::Users -e 'my $user = DCA::User->fetch("rlrevell");
> > > >$user->_o_clear; print $user->as_string'
> > > 
> > > A few thoughts:
> > > 
> > > a) that should be '$user->o_clear', but it might be a copy-n-paste typo?
> > > 
> > 
> > This is actually a typo in the SPOPS documentation (from
> > SPOPS::Manual::Object):
> > 
> >     Instead call the '_clear' method associated with a fieldname:
> >                                                                     
> >         $user->_m_name_clear;
> > 
> >     This explicitly sets the value to undef.
> > 
> > I have tried it both ways with negative results.
> > 
> > > b) do you have anything else in your ISA that uses AUTOLOAD that might 
> > > catch this first call to 'o_clear' (or 'foo_clear')?
> > > 
> > 
> > Not that I can tell.  Here is a snippet of my SPOPS config:
> >        class   => 'DCA::User',
> >         isa             => [ qw/ DCA::LDAPConnect SPOPS::LDAP/ ],
> >         rules_from      => [ qw/ DCA::ValidateUser / ],
> >         code_class      => [ qw/ DCA::LDAPUser / ],
> > 
> > DCA::LDAPConnect handles LDAP connection management and
> > DCA::ValidateUser is where my rulesets live.  Currently there is just
> > one method in there that is run as a pre_save_handler and updates
> > dependent attributes (like the home directory and GECOS field) when
> > primary attributes, like o(rganization), change.
> > 
> > DCA::LDAPUser just contains an as_string method that prints LDIF output.
> > 
> > I have not defined an AUTOLOAD method of my own anywhere.
> > 
> > > c) are you using SPOPS 0.80?
> > > 
> > 
> > Yes.
> > 
> > > d) do all the tests n t/00_base.t pass (esp. tests 48-50)?
> > >
> > 
> > As far as I can tell, yes:
> > 
> > PERL_DL_NONLAZY=1 /local/bin/perl5.8.0 "-MExtUtils::Command::MM" "-e"
> > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
> > t/00_base.....................ok
> > t/01_tie......................ok
> > t/02_tie_strict...............ok
> > etc.
> > 
> > > e) I assume that 'use'ing DCA::Users invokes SPOPS::Initialize?
> > >
> > 
> > Yes.  All other SPOPS functionality works fine; I can fetch a user,
> > update attributes, and save the user fine.  It's just the foo_clear
> > methods that don't seem to work.
> >  
> > > f) does '$user->{o} = undef' work as expected?
> > > 
> > 
> > Yes; the resulting object has the o set to undef.  The problem is that
> > when I then go to call $user->save, it tries to save the user with the o
> > attribute set to undef, which causes a schema violation in the case that
> > the user is modified to an objectclass that does not allow the attribute
> > in question.
> > 
> > The specific problem I am having is that when a user is modified from an
> > account type that has dialup access to one that does not, I have a
> > dcanethours field that needs to be deleted, as this field specifies the
> > number of hours per month a user is allowed to be dialed in.
> > 
> > Thanks for your help; SPOPS has been invaluable to this project.
> > 
> > > Chris
> > > 
> > > --
> > > Chris Winters
> > > Creating enterprise-capable snack systems since 1988
> > >