Clases, tablas y globals - ¿Cómo funcionan?

Class try.Point Extends %Persistent [DDLAllowed]
{

Property X;
Property Y;
}

Podríamos igualmente utilizar este DDL para crearla:

CREATE Table try.Point (
    X VARCHAR(50),
    Y VARCHAR(50))

Y se crearía la misma clase.

Después de la compilación, nuestra nueva clase debería tener una estructura Storage autogenerada que define el mapeo de globals a los datos en las columnas o propiedades:

Storage Default
{
<Data name="PointDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>X</Value>
</Value>
<Value name="3">
<Value>Y</Value>
</Value>
</Data>
<DataLocation>^try.PointD</DataLocation>
<DefaultData>PointDefaultData</DefaultData>
<IdLocation>^try.PointD</IdLocation>
<IndexLocation>^try.PointI</IndexLocation>
<StreamLocation>^try.PointS</StreamLocation>
<Type>%Library.CacheStorage</Type>
}

¿Qué está pasando aquí?

Desde abajo hacia arriba (en negrita está lo importante, puedes ignorar el resto por ahora):

• Type: tipo de almacenamiento generado. Een nuestro caso este es el tipo de almacenamiento por defecto para las clases persistentes
• StreamLocation - nombre del global donde se almacenan los Streams
• IndexLocation - nombre del global donde se almacenan los índices
• IdLocation - nombre del global donde almacenamos el contador del ID autoincremental
• DefaultData - nombre del elemento de almacenamiento XML que define el mapeo entre las columnas/propiedades y el global
• DataLocation - nombre del global donde almacenamos los datos

En este momento nuestro DefaulData es PointDefaultData, así que vamos a verlo.  En esencia nos dice qué nodo del global almacena qué valor, con la siguiente estructura:

• 1 - %%CLASSNAME
• 2 - X
• 3 - Y

De forma que podemos esperar que nuestro global tenga esta pinta:

^try.PointD(id) = %%CLASSNAME, X, Y

Si sacamos por pantalla el valor del global, inicialmente estará vacío, porque no hemos añadido ningún dato:

zw ^try.PointD

Vamos a añadir un objeto:

set p = ##class(try.Point).%New()
set p.X = 1
set p.Y = 2
write p.%Save()

Revisamos el global de nuevo y ¿qué tenemos?

zw ^try.PointD
^try.PointD=1
^try.PointD(1)=$lb("",1,2)

Como puedes ver, nuestra estructura esperada (%%CLASSNAME, X, Y) está establecida con $lb("",1,2), que corresponde a las propiedades X e Y de nuestro objeto (%%CLASSNAME es una propiedad del sistema, podemos ignorarla por ahora). 

Podemos igualmente añadir una nueva fila mediante SQL:

INSERT INTO try.Point (X, Y) VALUES (3,4)

Ahora nuestro global tiene esta pinta:

zw ^try.PointD
^try.PointD=2
^try.PointD(1)=$lb("",1,2)
^try.PointD(2)=$lb("",3,4)

De esta forma, siempre que añadimos datos vía objetos o SQL, éstos son almacenados de acuerdo a la definición del Storage (eEs posible modificar manualmente la definición del Storage - puedes probar tú mismo y ver qué pasa).

Ahora bien, ¿qué pasa cuando queremos ejecutar una consulta SQL?

SELECT * FROM try.Point

Esta consulta se traduce en código ObjectScript, que itera sobre el global definido y puebla las columnas en base a la definición del Storage.

Ahora vamos a por las modificaciones. Borremos todos los datos de la tabla.

DELETE FROM try.Point

Veamos el global después de esto:

zw ^try.PointD
^try.PointD=2

Fijaos que solo el contador del ID se mantiene, de esta forma el siguiente nuevo objeto/fila tendrá el ID=3. Nuestra clase y tabla continúa existiendo.

Pero ¿qué pasa si hacemos?:

DROP TABLE try.Point

Esto destruye nuestra tabla, clase y borra todo el global.

zw ^try.PointD

Espero que siguiendo este ejemplo ahora entiendas mejor cómo los globals, las clases y las tablas se corresponden unos con otros.