- Timestamp:
- 2018-11-05T16:43:30+13:00 (5 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
main/trunk/greenstone2/perllib/plugins/GreenstoneSQLPlugin.pm
r32565 r32570 218 218 my ($file, $oids, $archivedir) = @_; 219 219 220 my $rv = $self->SUPER::remove_one(@_); 221 220 222 print STDERR "@@@ IN SQLPLUG::REMOVE_ONE: $file\n"; 221 223 222 #return undef unless $self->can_process_this_file($file); # NO, DON'T DO THIS :224 #return undef unless $self->can_process_this_file($file); # NO, DON'T DO THIS (inherited remove_one behaviour) HERE: 223 225 # WE DON'T CARE IF IT'S AN IMAGE FILE THAT WAS DELETED. 224 # WE CARE ABOUT REMOVING THE DOCOID OF THAT IMAGE FILE FROM THE DB 225 226 # WE CARE ABOUT REMOVING THE DOCOID OF THAT IMAGE FILE FROM THE SQL DB 227 # SO DON'T RETURN IF CAN'T_PROCESS_THIS_FILE 228 226 229 print STDERR "*****************************\nAsked to remove_one oid\n***********************\n"; 227 230 228 231 my $gs_sql = $self->{'gs_sql'} || return 0; # couldn't make the connection or no db etc 229 if(scalar @$oids> 1) {230 print STDERR "TODO: We now have reason to optimise GreenstoneSQLPlugin::remove_one() by using dbi::prepare() + dbi::execute() instead of dbi::do().\n";232 if(scalar (@$oids) > 1) { 233 print STDERR "TODO: As there's more than 1 docid, we now have reason to optimise GreenstoneSQLPlugin::remove_one() by using dbi::prepare() + dbi::execute() instead of dbi::do().\n"; 231 234 } 232 235 … … 242 245 } 243 246 } 244 return 1;247 return $rv; 245 248 } 246 249 … … 292 295 293 296 # For now, we have access to doc_obj (until just before super::close_document() terminates) 294 295 # no need to call $self->{'doc_obj'}->set_OID($oid); 296 # because either the OID is stored in the SQL db as meta 'Identifier' alongside other metadata 297 # or it's stored in the doc.xml as metadata 'Identifier' alongside other metadata 298 # Either way, Identifier meta will be read into the docobj automatically with other meta. 299 297 298 # OID parsed of docsql.xml file does need to be set on $doc_obj, as noticed in this case: 299 # when a doc in import is renamed, and you do incremental import, it is marked for reindexing 300 # (reindexing is implemented by this plugin as a delete followed by add into the sql db). 301 # In that case, UNLESS you set the OID at this stage, the old deleted doc id (for the old doc 302 # name) continues to exist in the index at the end of incremental rebuilding if you were to 303 # browse the rebuilt collection by files/titles. So unless you set the OID here, the deleted 304 # doc oids will still be listed in the index. 305 $self->{'doc_obj'}->set_OID($oid); 306 300 307 print STDERR " GreenstoneSQLPlugin processing doc $oid (reading into docobj from SQL db)\n" 301 308 if $self->{'verbosity'} > 0;
Note:
See TracChangeset
for help on using the changeset viewer.