Checkpoint del Módulo 3

En este módulo has pasado de fabricar registros con new a pedírselos a la base de datos, que es lo que hace el 90 % del código Apex real. Antes de escribir, piensa en la pregunta: casi siempre hay una consulta que la responde sola, sin bucles de más.

Lo que has aprendido, sub-lección a sub-lección

1 · Anatomía. SELECT son las columnas del informe y FROM su Report Type. La consulta va entre corchetes y devuelve una List. Solo puedes leer los campos que pediste, y asignar a un solo registro falla si no hay filas.

2 · WHERE, ORDER BY, LIMIT. Los filtros, la lógica de filtros y el orden del informe. Texto entre comillas simples, un solo =, LIKE con %, IN para varios valores, literales de fecha como THIS_QUARTER. Las cláusulas van siempre en el mismo orden.

3 · Relaciones. Hacia el padre con un punto, como en una fórmula entre objetos (Account.Name, Customer__r.Name). Hacia los hijos con una subconsulta sobre el nombre de relación en plural, como una related list. Filtro cruzado con IN (SELECT ...).

4 · Enlaces y dinámico. :variable mete valores de Apex en la consulta sin riesgo. IN :conjunto filtra por muchos Ids de una vez: el patrón Set → IN → Map. Database.query solo cuando la forma de la consulta cambia, y nunca pegando lo que escribe el usuario.

5 · Agregados. COUNT, SUM, AVG, MIN y MAX con GROUP BY son el informe de resumen. Devuelven AggregateResult, que lees por alias con get() y casting. WHERE filtra filas; HAVING, grupos.

6 · SOSL. La búsqueda global en código: FIND, IN, RETURNING. Una lista por objeto, en el orden del RETURNING. Para cuando sabes el texto pero no dónde está.

La regla que se lleva el Módulo 4

La nutria: ¿Y por qué no un Flow? Porque así fue como reventó

El primer intento de la revisión por región fue un flow: Get Records de las cuentas, un Loop y, dentro, un Get Records de sus oportunidades. Con 80 cuentas iba bien; la región EMEA tiene 140 y el flow murió en «Too many SOQL queries: 101». Se podía rehacer con el operador In y otro Loop para sumar a mano los importes de cada cuenta. En Apex son dos consultas: una subconsulta para contar y un GROUP BY para sumar. El límite es de la transacción, y Flow y Apex lo comparten.

Ahora en tu Developer Org

Tu Developer Org trae datos de ejemplo: cuentas como Edge Communications o United Oil & Gas, con sus contactos y oportunidades. Vas a consultarlos de verdad.

1. Abre la Developer Console (menú del engranaje) y, en la parte de abajo, la pestaña Query Editor.
2. Pega una consulta sin corchetes, por ejemplo SELECT Name, Industry, (SELECT LastName FROM Contacts) FROM Account ORDER BY Name, y pulsa Execute. Verás una tabla, como un informe.
3. Prueba un agregado: SELECT StageName, COUNT(Id), SUM(Amount) FROM Opportunity GROUP BY StageName. Compara los números con un informe de resumen de Oportunidades por etapa: tienen que coincidir.
4. Escribe mal un campo a propósito (Industy) y ejecuta: lee el error. Ahora ya sabes qué te diría el compilador al guardar una clase.
5. Por último, pega tu solución del ejercicio en Debug → Open Execute Anonymous Window, cambia la región a una que exista en tus datos (por ejemplo 'CA' o 'NY'), marca Open Log y mira el resultado con Debug Only.