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

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

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
> >