Projector Capabilities

[AlexWeinstein92]

In projectors themselves multiple records should be allowed. This would allow for multiple tables in a single projector for joining on result.

In on-clauses of projector handlers ideally the following is possible:

on event:

• create, update, or remove for record type
• with index for create, for example create record Table1Fields with index Table1Fields.id
• with for checking rows to alter
  • update record Table1Fields with Table1Fields.Name equals Event.Name
    • can perform action on multiple records
    • remove records Table1Fields with Table1Fields.DateCreated less than today() [now() is also necessary]
    • when for conditional on with:
    • create records ProductOrderFields with index Event.id when ProductFields.SKU equals Event.SKU (prevents Orders with bad SKUs having Product entries created for them)
    • set field in record
    • set Table1Fields.Name to Event.Name

on query:

• filter
• join
• piping ie use result of previous step
• sorting of results
• transforming results to use a Map

[reid-spencer]

This raises questions about how we should model projections in RIDDL. Assuming the intended target is a relational database makes it too rigid, in my view. I will try to synthesize a more abstract solution.

[reid-spencer]

@AlexWeinstein92 - some conclusions I've made from considering your suggestion:

• Projectors cannot be queried. They have no data. They are merely transformation services. Consequently, I've removed the ability for Projectors to have "on query " clauses in a recent push. Queries should be on repositories
• All of the items in your on event bullet points can/should be done by sending messages to the repository.
• There needs to be a clause in the projector to indicate which repository is the backing store that the projector updates. This is not yet implemented, but the syntax will be like:

  updating repository MyRepository