Opened 15 years ago
Last modified 14 years ago
#950 closed enhancement
Ois.UseCache — at Version 1
Reported by: | Javier Portugal | Owned by: | Víctor de Buen Remiro |
---|---|---|---|
Priority: | normal | Milestone: | Mantainance |
Component: | OIS | Version: | 2.0.1 |
Severity: | major | Keywords: | |
Cc: |
Description (last modified by )
Intenté hacer una función para no usar Ois.UseModule
cuando lo que se pretende es generar como caché el contenido final de un archivo en el que se efectúan acciones no declarativas
// Variable global Real Alg.SPFRes.LoadFromOza = 1; ////////////////////////////////////////////////////////////////////////////// Set Ois.UseCache(Text fileTOL, Text fileOza) ////////////////////////////////////////////////////////////////////////////// { Set If( And( Alg.SPFRes.LoadFromOza, FileExist(fileOza) ), Set Ois.Load(fullFileOza)[1], { Real Ois.Store(Include(fileTOL), fileOza); Set Ois.Load(fileOza)[1] } ) };
El problema es que al cargar desde el oza las funciones y objetos no son globales como si se hubiese cargado con Include
u Ois.UseModule
Change History (1)
comment:1 Changed 15 years ago by
Description: | modified (diff) |
---|---|
Milestone: | → Mantainance |
Status: | new → accepted |
Version: | → 2.0.1 |
Note: See
TracTickets for help on using
tickets.
Yo creo que hay que pensarse un poco mejor el objetivo y la API correspondiente para eliminar la variable global y luego implementarla en C++, pues es la forma más sencilla de que devuelva objetos globales.
Por ejemplo, lo que has propuesto antes se podría hacer sin variables globales con una función built-in con un argumento opcional con valor por defecto 1, lo cual fuerza a usar el .oza si existe
Sin embargo, yo creo que es más práctico que el argumento opcional sea un indicador de caducidad pues aporta mayor flexibilidad.
Si no existe la cache se construye automáticamente sin más contemplaciones. Internamente la función calculará la edad relativa actual como la resta entre la fecha de la caché .oza y el archivo .tol original. Para asegurar la integridad referencial, la caché también deberá ser reconstruida siempre que el fichero original haya sido actualizado dejando obsoleta la caché, o sea, si su edad relativa es negativa. Por lo tanto, no se debe tocar el .tol salvo que realmente se quiera modificar su contenido. Si se altera por error siempre es posible modificar la fecha del archivo .oza mediante el comando touch del sistema operativo para que la edad relativa sea positiva, pero la norma debe ser dejar congelado el archivo de origen. Si la caché está obsoleta la borrará por lo que se tratará como si no hubiese sido creada nunca, es decir se reconstruirá y se recalculará su edad relativa, así que podemos descartar en lo que resta el caso de edad relativa negativa.
Si se le pasa como argumento opcional una caducidad positiva, entonces comprueba si la caché existe; y sólo la reconstruye si ha caducado, es decir, si la edad relativa es positiva y mayor que la caducidad propuesta. El valor por defecto de caducidad infinita indica que el .oza no caduca nunca. Si se le pasa una caducidad nula, negativa o desconocida, se fuerza la reconstrucción de la caché tanto si existía como si no y fuera o no obsoleta. Todo esto permite mucho más control por parte del usuario que un simple flag booleano al mismo tiempo que se asegura la integridad referencial de una forma completamente natural.
Ejemplos: