[Isis-users] Problema com fullinv em base de dados ABCD

Wed Oct 24 17:26:53 CEST 2018

Edwin

El problema es que hay que tomar en cuenta los límites de la 
arquitectura de los registros Isis, que son diferentes si se usan las 
versiones 1660, ffi o BigIsis
La versión de ABCD 1.5.x usa 1660 y la versión ABCD 2.0 puede usar, 
según lo defina el usaurios, cualquiera de las dos arquitecturas,
Voy a referirme a los límites para 1660, porque es la que usa Edwin, la 
información que sigue no está documentada, es el resultado de la 
experiencia de "try and error"

Empecemos con la estructura de un registro Isis.
Sería conveniente que tuvieran a mano el manual del CISIS

El registro tiene tres partes: Leader, Directory, Data
El Directory tiene las entradas en un array, de los datos que están en 
la parte Data
Pongamos un ejemplo de un registro tomado del CDS que viene de modelo 
con el Winisis (que tiene límites menores al 1660)

*mx CDS from=4*
mfn=     4
  44  «Methodology of plant eco-physiology: proceedings of the 
Montpellier Symposium»
  50  «Incl. bibl.»
  69  «hygrometers»
  69  «plant transpiration»
  69  «moisture»
  69  «water balance»
  24  «An Electric hygrometer apparatus for measuring water-vapour loss 
from plants in the field»
  26  «^c1965»
  30  «^ap. 247-257^billus.»
  70  «Grieve, B.J.»
  70  «Went, F.W.»
951  «##^aBRS»

Si quiero mirar la estructura SIN datos pongo:
*mx CDS from=4 -all +dir*
mfn=     4|dir=  1|tag=   44|pos=    0|len=   77
mfn=     4|dir=  2|tag=   50|pos=   77|len=   11
mfn=     4|dir=  3|tag=   69|pos=   88|len=   11
mfn=     4|dir=  4|tag=   69|pos=   99|len=   19
mfn=     4|dir=  5|tag=   69|pos=  118|len=    8
mfn=     4|dir=  6|tag=   69|pos=  126|len=   13
mfn=     4|dir=  7|tag=   24|pos=  139|len=   89
mfn=     4|dir=  8|tag=   26|pos=  228|len=    6
mfn=     4|dir=  9|tag=   30|pos=  234|len=   20
mfn=     4|dir= 10|tag=   70|pos=  254|len=   12
mfn=     4|dir= 11|tag=   70|pos=  266|len=   10
mfn=     4|dir= 12|tag=  951|pos=  276|len=    7

Aqui se tiene la estructura (lay-out) del directorio de ese registro
Como verán, tiene 12 entradas de campo, y por ejemplo del campo 69 
(descriptores) hay 4 ocurrencias
La cantidad máxima de entradas en el directorio (no está documentado) 
está entre 750 y 800 para 1660. Además la cantidad máxima de 
repeticiones de un campo (ocurrencias, no está documentado) es menor a 
100, o sea, no se pueden tener 200 descriptores, porque cuando van a 
editarlo se rompe el registro (prueben si gustan en Winisis ...)

Entonces, veamos qué pasa cuando se genera el archivo invertido,
El tema es que la FST va a generar en el proceso de indexación campos 
virtuales en el registro
Tomemos por ejemplo el campo v24 (titulo) y lo indexamos por palabra.
Para distinguir las entradas (tags) originales de los datos de los tags 
virtuales que generarán los posts, pondremos 666 para esos datos
*
**mx cds from=4 -all +dir  "fst=666 8 '/TW_/',v24"*
mfn=     4|dir=  1|tag=   44|pos=    0|len=   77
mfn=     4|dir=  2|tag=   50|pos=   77|len=   11
mfn=     4|dir=  3|tag=   69|pos=   88|len=   11
mfn=     4|dir=  4|tag=   69|pos=   99|len=   19
mfn=     4|dir=  5|tag=   69|pos=  118|len=    8
mfn=     4|dir=  6|tag=   69|pos=  126|len=   13
mfn=     4|dir=  7|tag=   24|pos=  139|len=   89
mfn=     4|dir=  8|tag=   26|pos=  228|len=    6
mfn=     4|dir=  9|tag=   30|pos=  234|len=   20
mfn=     4|dir= 10|tag=   70|pos=  254|len=   12
mfn=     4|dir= 11|tag=   70|pos=  266|len=   10
mfn=     4|dir= 12|tag=  951|pos=  276|len=    7
mfn=     4|dir= 13|tag=  666|pos= 283|len=   17
mfn=     4|dir= 14|tag=  666|pos=  300|len=   23
mfn=     4|dir= 15|tag=  666|pos=  323|len=   25
mfn=     4|dir= 16|tag=  666|pos=  348|len=   24
mfn=     4|dir= 17|tag=  666|pos=  372|len=   18
mfn=     4|dir= 18|tag=  666|pos=  390|len=   24
mfn=     4|dir= 19|tag=  666|pos=  414|len=   20
mfn=     4|dir= 20|tag=  666|pos=  434|len=   21
mfn=     4|dir= 21|tag=  666|pos=  455|len=   19
mfn=     4|dir= 22|tag=  666|pos=  474|len=   20
mfn=     4|dir= 23|tag=  666|pos=  494|len=   22
mfn=     4|dir= 24|tag=  666|pos=  516|len=   18
mfn=     4|dir= 25|tag=  666|pos=  534|len=   19
mfn=     4|dir= 26|tag=  666|pos=  553|len=   21

Ahora tenemos en memoria un registro virtual ISIS que tiene 26 entradas, 
12 son los datos originales y 14 los que agrega el proceso de indexación 
con la FST

Para hacer la historia corta, si tienen una FST muy detallada, con 
extracciones múltiples por campos, subcampos, y además palabras 
individuales de textos, entonces seguramente van a tener una de dos 
situaciones (o las dos), (a) la FST generó más de 800 entradas en el 
directorio, o tenemos 150 o 200 palabras procedentes de un texto, y por 
cualquiera de las dos situaciones el registro se quiebra y genera 
archivos dbn.LK1/2 corrompidos que cuando se llega a la etapa del IFLOAD 
se rompe el proceso

Edwin, para probar esta tesis, ingresa por comando al servidor, y usando 
tu base pones

mx <base> fst=@  -all +dir  from=<n> count=1  now > pepe.txt  y luego 
mira el archivo pepe.txt

La solución es tomar podar/depurar la FST para evitar postings innecesarios.
Los campos de textos largos, si se van a indexar con palabras, una 
solución es limitar el largo del texto a solo el comienzo, por ejemplo
  1  8  '/TW_/', s(v100)*0.100   o alguna cosa similar

Saludos
Ernesto Spinak
------------------------------------------------------------------------

l 24/10/2018 a las 11:03, Edwin Hübner escribió:
> Agradezco a todos los que han intentado ayudarme, pero 
> desafortunadamente no he tenido éxito en ninguno de los métodos sugeridos.
>
> El método de Juan, no interrumpe ni en la exportación ni en la 
> inportación.
>
> Con el método de Alberto, ejecutando fullinv con mx, tell = 1 sucede 
> lo siguiente:
>
> 1) Con la base de datos actual termina así:
> +++ 13177/0
> +++ 13178/0
> +++ 13179/0
> +++ 13180/0
> +++ 13181/0
> +++ 13182/0
> +++ 13183/0
> +++ 13184/0
> +++ 13185/0
> +++ 13186/0
> +++ 13187/0
> +++ 13188/0
> +++ 13189/0
> fatal: fullinv / ifload
> Donde 13189 es el último mfn
>
> 2) con la base de datos exportada e importada termina así
> +++ 53399 CC_ / CC_ / CD▒S GRABACIONES SEMINARIO
> +++ 53400 CC_ / CC_ / CD▒S SIN IDENTIFICACION
> +++ 53401 CC_ / CC_ / CD▒S TCC GESTIÓN FINANCIERA EMPRESARIAL NEXTEL TURMA
> +++ 53402 CC_ / CC_ / CD▒S ▒ VIDEOS, AUDIO Y FOTOS ▒ QH 2011
> +++ 53403 CC_ / CC_ / CD▒S: DETALLE DE SERVICIOS PRESTADOS EMBRATEL; C
> fatal: fullinv / ifload
> ¿Que significa?
> saludos
> Edwin
>

-- 
   .^.                                .^.
   ( )                                ( )
   ===                                ===
  =[=]================================[=]=
   | |  Ernesto Spinak                | |
   | |  spinaker at adinet.com.uy        | |
   | |  Montevideo, Uruguay           | |
   | |  tel/fax  (598) 2622-3352      | |
   | |  celular  (598) 99612238      | |
  =[=]================================[=]=
   ===                                ===
   ( )                                ( )
    V                                  V

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.iccisis.org/pipermail/isis-users/attachments/20181024/e9c9aab7/attachment.html>