Me uní a InterSystems hace menos de un año. Sumergirme en ObjectScript e IRIS fue emocionante, pero también estuvo lleno de pequeñas sorpresas que me hicieron tropezar al principio. En este artículo recojo los errores más comunes que yo, y muchos compañeros nuevos, cometemos, explico por qué ocurren y muestro ejemplos concretos junto con soluciones prácticas. Mi objetivo es ayudar a otros desarrolladores que empiezan a ahorrar tiempo y evitar los mismos obstáculos en el camino.
1. Perderse entre las clases del sistema y no saber por dónde empezar
El problema: ObjectScript/IRIS viene con muchas clases y paquetes de sistema (%Library, %SYS, %Persistent, %SQL, etc.). Como nuevo desarrollador, es difícil saber qué clase o patrón se ajusta a una tarea. Recuerdo intentar encontrar una clase persistente adecuada y no estar seguro de si debía extender %Persistent o usar una clase de tipo registro.
Por qué importa: Elegir un enfoque equivocado desde el inicio hace que el código sea más difícil de mantener y se integre peor con las funciones de IRIS (índices, seguridad, SQL).
Consejo: Partid siempre de la necesidad concreta (¿guardar registros? ¿exponer SQL? ¿compartir objetos entre procesos?) y luego buscad en la Class Reference la capacidad relevante (persistencia, índices, colecciones). Usad Studio o la extensión de InterSystems para VS Code para explorar las clases de manera interactiva e inspeccionar ejemplos.
2. Sobrecarga con la documentación: no saber las palabras clave correctas
El problema: La documentación es muy completa, pero si no conocéis el nombre exacto de la clase o el término, las búsquedas devuelven muchas páginas no relacionadas. Al principio pasaba mucho tiempo porque aún no conocía los términos canónicos.
Por qué importa: Perdéis tiempo y podéis acabar implementando patrones poco óptimos.
Consejo:
- Buscad en la Developer Community ejemplos prácticos (buscad por “persistent class example”, “ObjectScript transaction TSTART example”, etc.).
- Usad la extensión de InterSystems para VS Code, que puede saltar directamente a las definiciones de clases.
- Al buscar en la documentación, combinad nombres de clases y acciones: por ejemplo,
“%Persistent property index example”.
3. Olvidar .. al llamar a un método local
El problema: Llamar a un método de la misma clase sin .. provoca que la llamada no se reconozca en tiempo de ejecución.
Incorrecto:
Class MyClass Extends %Persistent {
Method DoWork()
{
Do Hello() // wrong: this is not a local method invocation
}
Method Hello()
{
Write "Hello", !
}
}
Correcto:
Method DoWork() {
Do ..Hello() // correct: local method call
}
Consejo: Cuando os aparezcan errores de “Unknown routine” al intentar usar métodos que veis en la clase, comprobad si habéis usado .. para las llamadas a métodos de la propia clase.
4. Confusión entre globals y variables locales
El problema: ObjectScript distingue entre globals (persisten entre sesiones, por ejemplo ^MyGlobal) y variables locales (en memoria, con un alcance limitado). Los nuevos desarrolladores suelen usar uno cuando en realidad necesitan el otro.
SET localVar = 10 // exists only during the current process/session
SET ^globalVar = 20 // persists in the database across processes and sessions
Consejo: Usad clases persistentes para los datos que deban almacenarse a largo plazo. Limitad el uso de globals solo a necesidades muy específicas de bajo nivel o cuando entendáis bien sus consecuencias.
5. Codificar directamente en globals en lugar de usar clases persistentes
El problema: Mi primer instinto fue el “rápido y sucio”: escribir directamente en ^MyGlobal. Eso funciona, pero evita las ventajas basadas en clases: esquema, índices, acceso vía SQL y seguridad.
Un mejor enfoque:
Class Person Extends %Persistent
{
Property Name As %String;
Property DOB As %Date;
}
Consejo: Dad siempre preferencia a las clases %Persistent para los datos de la aplicación. Os ofrecen un modelo más limpio e integran automáticamente con SQL e índices.
6. Ignorar las transacciones (TSTART / TCOMMIT)
El problema: A veces los desarrolladores realizan varias escrituras pensando que son atómicas. Sin un control explícito de transacciones, un fallo parcial puede dejar los datos en un estado inconsistente.
TSTART
// multiple updates
TCOMMIT
Consejo: Identificad las unidades lógicas de trabajo y envolvedlas en transacciones. Si algo puede fallar a mitad, usad TSTART / TROLLBACK / TCOMMIT. Tened en cuenta que IRIS soporta transacciones anidadas: varias llamadas a TSTART incrementan el nivel de transacción, y todos los niveles deben ser confirmados (o revertidos) antes de que los cambios sean definitivos.
7. Malentender las opciones de SQL: Embedded SQL vs %SQL.Statement
El problema: Embedded SQL (bloques UPDATE, SELECT dentro de ObjectScript) y la API %SQL.Statement están disponibles; elegir sin conocer sus pros y contras puede llevar a un código poco claro o difícil de mantener.
Recomendación: Usad Embedded SQL para consultas fijas/estáticas dentro de rutinas; usad %SQL.Statement cuando necesitéis construir y ejecutar SQL de forma dinámica.
8. Saltarse un manejo adecuado de errores
El problema: No usar TRY/CATCH ni señalizar los errores correctamente dificulta la depuración y reduce la fiabilidad del código.
TRY
{
// code that may fail
} CATCH ex
{
Write "Error: ", ex.DisplayString(),!
}
Consejo: Envolved siempre las operaciones de riesgo (I/O, llamadas externas, SQL dinámico) con manejadores de errores y registrad mensajes informativos.
Notas finales
Al principio escribía en globals por comodidad y más tarde tuve que dedicar tiempo a refactorizar hacia clases persistentes. Esa refactorización me enseñó el valor de diseñar los modelos de datos desde el principio y de usar las herramientas que ofrece IRIS.
Mis mejores hábitos ahora son: hacer pequeños experimentos, buscar con frecuencia en la Developer Community y tener siempre presentes las transacciones y el manejo de errores desde el inicio.
Si sois nuevos: tratad vuestras primeras tareas como experimentos, cread pequeñas clases persistentes, probad con SQL incrustado sencillo y usad el Management Portal y el explorador de clases de VS Code para inspeccionar las clases del sistema. Haced preguntas en la Developer Community; muchos otros se han encontrado con las mismas “trampas” al empezar.
Para más información: consultad la documentación oficial de ObjectScript y la Developer Community para ejemplos y patrones.
.png)
Open Exchange