parse-server: Support wildcard classname in cloud triggers
New Feature / Enhancement Checklist
- I am not disclosing a vulnerability.
- I am not just asking a question.
- I have searched through existing issues.
Current Limitation
Currently user have to define cloud triggers one by one. If we have a recurring logic inside of cloud trigger, defining triggers become too hard.
Feature / Enhancement Description
We should be able to define one trigger that applies to all class. Unless that class has its own triggers.
Example Use Case
Parse.Cloud.beforeSave("Test", (request) => {
//this trigger will be executed for only Test class
});
Parse.Cloud.beforeSave("*", (request) => {
//this trigger will be executed for every class except Test class
});
Alternatives / Workarounds
No known workaround or alternative.
3rd Party References
Its similar to setting SSL sertificates to multiple subdomains.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 51 (29 by maintainers)
Order can matter depending on what the trigger does. We may well say that the execution order is undefined for now. That simplifies the PR, leaving the door open for future change without breaking anything.
Our philosophy is to not add restrictions for all developers of the basis of potential mistakes by some developers. We always aim for versatility. There are other ways (warnings, guidance, etc.) to “help” developers to not make mistakes.
You would need to refactor. It seems arbitrary to execute triggers on an inheritance order, it may work for some use cases, not for others. Using a holistic inheritance mechanism for triggers is likely the most intuitive and universal approach.
Interesting idea. The execution order seems arbitrary. If we go with inheritance principles, a trigger would be inherited by child and we would offer something like a
super()to execute the inherited trigger and one can override the trigger without callingsuper().That means one could define a trigger for
Parse.Objectwhich would be the default trigger, which I think @tremendus mentioned. A child class can then simply override the trigger in a OOO-similar syntax. That could make a regex or wildcard approach unnecessary. A difference being that OOO requires a tree inheritance, but regex allows an across-inheritance triggers, which means greater flexibility.I think this goes beyond this issue of “wildcard classname in cloud triggers” and requires discussion in a separate issue, if we want to pursue that alley.
I think this is a different topic. That is a developer responsibility. Regex has no type safety, it works on a lower level if you will. We cannot force a developer to write tests for their app, nor can we force a developer to only centrally subclass custom Parse Objects instead of writing multiple lines of
Parse.Object.extend('CustomClassName'). All best practices you mention make sense, and they are currently possible with Parse Server.Sure. Let me see what I can do.
Not sure why you suggest polling? This is not a question of apple or carrot, but rather of apple or grocery store (grocery store having apples, carrots and much more).
I want to make sure you understand the regex approach:
The approach to implement a regex syntax and execute all matching functions covers many use cases, including your specific use case. You can set it up to not execute a specific CF.
The approach you are suggesting may cover your specific use case, but it is restrictive and not versatile. That means it will be usable in less use cases. It is also problematic on other fronts:
*is not regex, this syntax is not easily extensible.For example, what you can do with regex:
User...A,B,C.Let me know where you see an issue with the regex approach, or why you think a restrictive approach is better.
@mtrezza I have edited the issue.