Aplicación practica de Bundles Class

Cuando lees un artículo de una nueva API normalmente la gente se suele copiar en los ejemplos, o a lo sumo desarrolla uno de ellos un poquito más, es raro hablar de una Bundle Class o lo que se ha programado en ella ya que suele ser parte de la lógica de negocio.

Este texto son unas reflexiones de Statu en el Slack de Drupal-es en el que termina encontrando otra "aplicación" práctica para resolver una feature y obviamente implica implementar métodos en una Bundle Class.


El problema:
 

Buenos días a todos! A ver si alguien se ha enfrentado a esto:Tengo un evento con un campo de tipo smart_date recurrente (drupal.org/project/smart_date). Básicamente es un campo de fecha con varios deltas. Cada delta es una fecha distinta en función de la frecuencia del evento. Por ejemplo,  el evento "Navidad" tendría en el field_date dos valores:

• delta 0:

• value: 25/12/2022 00:00
• end_value: 25/12/2022 23:59

• delta 1:

• value: 25/12/2023 00:00
• end_value: 25/12/2023 23:59

El módulo se encarga automáticamente de crear siempre una instancia de la fecha del evento en el futuro a través de un cronjob (no estoy seguro al 100% pero por ahí van los tiros). Pero bueno, eso tampoco es muy importante. Lo importante es que el mismo field guarda varios valores de la fecha.Ahora creo un índex en Search API e indexo dos campos:

•  field_date
• field_date_end_value

Y por último, creo una vista con un filtro para sacar los eventos que están ocurriendo en este mismo instante:

• field_date > now
• field_date_end_value < now

Qué pasa? Que search API encuentra un valor del campo indexado field_date  que está en el futuro (el del año 2023) y encuentra un valor field_date_end_value que está en el pasado (el del año 2022). Por lo que siempre me muestra los eventos recurrentes como que están sucendiendo en este instante.Alguien ha tenido este problema?

Y la solución que el mismo ha propuesto:
 

He pensado ya que voy a hacer:

• Implementar 3 métodos en el Event bundle class:

• isRecurrent()
• getNextOcurrence() - devuelve la fecha más cercana que tiene el end_date > now
• getLastOcurrence() - devuelve la fecha más cercana que tiene el end_date < now

• Implementar un Serach API Processor que cree y setee 4 campos nuevos en el índice usando los métodos anteriores:

• next_field_date_occurrence
• next_field_date_occurrence_end_value
• last_field_date_occurrence
• last_field_date_occurrence_end_value

• Cambiar las condiciones de la vista para usar:

• En los eventos pasados:

• last_field_date_occurrence_end_value < now

• En los current event:

• next_field_date_occurrence < now && next_field_date_occurrence_end_value > now

• En los upcoming events:

• next_field_date_occurrence > now

• Implementar un hook_cron que compruebe si los valores de getNextOcurrence() y de getLastOcurrence() son distintos a los indexados. Y en ese caso, reindexar