[RAS] Frustration

[Ivan Kurmanov]

Sorry about that, the error really means: the handle of the record in
question is a duplicate of another handle, in this case, of the one
that is used in a different file: bin/bpeajo/BPEA_2003_02_01.rdf.  And
that file does not have to be checked again (to see if that is a
conflict), because it was ready relatively recently and hasn't changed
since. Therefore RePEc::Index can safely draw the conclusion that the
handle is still in conflict and, therefore, it is excluded from the
processing.

Sometimes the decision about the conflict is deferred until the second
file is checked.

-ivan

On Sat, Feb 14, 2009 at 11:37 PM, Thomas Krichel <krichel at openlib.org> wrote:
>  Christian Zimmermann writes
>
>> I am getting really frustrated with some templates that just refuse to
>> load into RAS.
>>
>> This case is about Frank Westermann who cannot get
>> RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied
>> updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple
>> times, to no effect. I am at a loss now, as this has been dragging for
>> several weeks now.
>
>  From the log, when I try it
>
> Sat Feb 14 16:06:29 2009  request:
>  source: /home/aras/acis/bin/updareq [31834]
>  collection: RePEc
>  update: bin/bpeajo/BPEA_2003_02_Tornell.rdf ()
> U DATAFILE_START: bin/bpeajo/BPEA_2003_02_Tornell.rdf
> file: bin/bpeajo/BPEA_2003_02_01.rdf
> no need to check it to draw conclusions
> the record is still there
> U DATAFILE_FINISH: bin/bpeajo/BPEA_2003_02_Tornell.rdf
> Sat Feb 14 16:06:29 2009 processed bin/bpeajo/BPEA_2003_02_Tornell.rdf in RePEc
> Sat Feb 14 16:06:29 2009 time:  0 wallclock secs ( 0.24 usr +  0.01 sys =  0.25 CPU)
>
>
>  I have never seen
>
> no need to check it to draw conclusions
> the record is still there
>
>  before.
>
>
>  It does not appear that the record is in the database
>
> aras at nebka:~$ mysql
> Welcome to the MySQL monitor.  Commands end with ; or \g.
> Your MySQL connection id is 72470
> Server version: 5.0.32-Debian_7etch8-log Debian etch distribution
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> use rdb;
> Reading table information for completion of table and column names
> You can turn off this feature to get a quicker startup with -A
>
> Database changed
> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
> Empty set (0.00 sec)
>
> mysql> select id from resources where id = "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
> Empty set (0.00 sec)
>
> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112%";
> Empty set (0.00 sec)
>
>  In phpmyadmin, running
>
> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112' USING latin1) COLLATE latin1_swedish_ci
>
>  gives an empby set, and so does
>
> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:%' USING latin1) COLLATE latin1_swedish_ci
>
>
>  In the code aras at nebka:~/acis/lib/RePEc/Index/History/Handle.pm
>
>
>   if ( $status ) { # will queue
>        p "will check it";
>        push @current, $_;
>        $files_to_check -> {$fn} = 1;
>
>      }
>      else {
>        p "no need to check it to draw conclusions";
>
>        # Is that file known to contain a record with the same id?
>        # CONSISTENCY CHECK
>
>        my $frec = $UPDATE -> get_file_record( $fn );
>        if ( $frec ) {
>          my $present_there;
>          my $list = $frec -> templates_list;
>          foreach ( @$list ) {
>            if ( $_ eq $id ) {
>              $present_there = 1;
>            }
>          }
>          if ( $present_there ) {
>            p "the record is still there";
>            push @current, $_;
>
>          }
>          else {
>            p "the record is no longer there";
>            push @lost_present_file, $fn;
>        }
>        else {
>          p "the file is no longer there";
>          push @lost_present_file, $fn;
>        }
>      }
>    }
>
>  It seems to think the record is there, but is not.
>
>
>  Cheers,
>
>  Thomas Krichel                    http://openlib.org/home/krichel
>                                RePEc:per:1965-06-05:thomas_krichel
>                                               skype: thomaskrichel
>
> _______________________________________________
> RAS-run mailing list
> RAS-run at lists.openlib.org
> http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
>