Support wildcard classname in cloud triggers

[uzaysan]

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.

[mtrezza]

Thanks for suggesting.

Please use the issue template provided and describe the feature in more detail.

The PR already makes the assumptions that the "trigger will be called for every class unless class has its own trigger".

This and possibly other aspects should be discussed in the issue.

[uzaysan]

@mtrezza I have edited the issue.

[mtrezza]

I think the obvious alternative would be to define a function that contains the recurring logic.

Can you explain the assumption that these generic Cloud Function definitions override a class specific definition?

[uzaysan]

You mean something like this?

Parse.Cloud.beforeSave("Test", (request)  => {
  recurringLogic(request);
});

const recurringLogic = (request)  => {
  //Logic
};

Or even like this:

Parse.Cloud.beforeSave("Test",recurringLogic);

const recurringLogic = (request)  => {
  //Logic
};

But user is still have to define trigger for every class.

Can you explain the assumption that these generic Cloud Function definitions override a class specific definition?

For example all classes has a user pointer. And Developer may want to assign the user that created the parse object. Developer can do this with this code:

Parse.Cloud.beforeSave("Test",(request) =>{
  if(!request.original){
    //assign user to newly created object
    request.object.set("user",request.user);
    return request.object;
  }
});

This is a simple code but if developer has many classes, defining the triggers manually would take too long. If developer has 100 classes, he/she has to write same code 100 times.

But I admit that 99% of projects doesn't go beyond 15-25 classes. And generally classes has seperate logic. But this feature would make coding easier for those who need it. Its rare. But since someone opened a thread on community forum, that means someone need it.

[mtrezza]

But user is still have to define trigger for every class.

Yes, I wanted to mention it as an alternative, so we understand what the status quo is. The issue says that no alternatives exist.

this feature would make coding easier for those who need it.

I agree, it seems to be a useful addition to Parse Server.

If user set trigger for class "*", that trigger will be called for every class unless class has its own trigger.

I would like to understand how you came to the assumption that these generic Cloud Function definitions should override a class specific definition. If I understand you correctly this means:

Parse.Cloud.beforeSave("Test", () => {
});

Parse.Cloud.beforeSave("*", () => {
  // This would not be called for `Test` because it has its own definition
});

[uzaysan]

Yes, I wanted to mention it as an alternative, so we understand what the status quo is. The issue says that no alternatives exist.

User still have to define triggers manually so not an exactly alternative.

I would like to understand how you came to the assumption that these generic Cloud Function definitions should override a class specific definition. If I understand you correctly this means:

This is because developer may want to seperate some class logic from the others. Just because you used wildcard triggers doesn't mean you cant use class specific triggers. If developer has a common logic for 50 class but different logic for a few class, they can use generic triggers for that classes.

Like this:

Parse.Cloud.beforeSave("Exception", () => {
  //This class is created by developer in cloud code. So we don't need to assign user to it.
});

//or

Parse.Cloud.beforeSave("_User", () => {
  //This class is already user. So assigning user to itself  wouldn't make sense.
});

Parse.Cloud.beforeSave("*", () => {
  // But this trigger will be called for the rest of the classes.
});

We are making the job easy while not limiting the developers options.
Edit:

I would like to understand how you came to the assumption that these generic Cloud Function definitions should override a class specific definition.

I think you meant class specific trigger override generic one. PR looks first class specific trigger. If there is no class specific trigger, then it uses wildcard trigger.

If I understand you correctly this means:

Parse.Cloud.beforeSave("Test", () => {
});

Parse.Cloud.beforeSave("*", () => {
// This would not be called for Test because it has its own definition
});

Yep. That's correct.

[mtrezza]

User still have to define triggers manually so not an exactly alternative.

Alternative here means how it can be done currently, without this enhancement. So we know where we are coming from. Could you add this to the issue description?

We are making the job easy while not limiting the developers options.

We are actually doing the opposite, because we implement a fixed rule in case of multiple definitions for the same class. You can make your feature more useful to more developers if you give some freedom to cover more use cases. The question is: if we have multiple definitions (specific and generic) for a class, how should they be handled?

• a) Execute the specific definition but ignore the generic definition ← currently suggested
• b) Execute the generic definition but ignore the specific definition
• c) Execute both definitions in some fixed order
• d) Execute both definitions in a developer customizable order

The above is roughly in order of complexity, meaning a) will be less work in the PR than d), but inversely, d) will be more useful to developers than a).

When choosing a concept we have to look at forward compatibility, meaning if we go for a) or b) now, we may have more difficulty going to c) or d) later, because it may be a breaking change.

[uzaysan]

Alternative here means how it can be done currently

Its still can't be done. Because we still have to write all class name manually which is what we are trying to escape.

The question is: if we have multiple definitions (specific and generic) for a class, how should they be handled?

a) Execute the specific definition but ignore the generic definition ← currently suggested
b) Execute the generic definition but ignore the specific definition
c) Execute both definitions in some fixed order
d) Execute both definitions in a developer customizable order

I think option A would be best. Option B is in least favorable in my opinion. Because It locks developers hand. Its either black or white. No between. And about option C and D, I would choose C. I would run class specific trigger first then execute generic trigger. But running two triggers for same class doesn't make sense to me. I mean I see your point but why use generic trigger if you already defined class specific trigger?

if we go for a) or b) now, we may have more difficulty going to c) or d) later, because it may be a breaking change.

Why would we wanna switch to the c or d in future? Can you give me an example

Edit: I miss read. You can Ignore the below.

How exactly? Solution A wont be a problem for old versions. Since old versions has only class specific triggers, PR will look class specific trigger first, If user defined it, It will execute. If its undefined, then it look for generic trigger. And since old versions doesn't have generic trigger parse will do what it do when you save an object and class doesn't have any trigger.

For the future versions, I really can't see how is this gonna be problem. Can you clarify this?

[mtrezza]

Its still can't be done. Because we still have to write all class name manually which is what we are trying to escape.

You could just iterate through the schema and get all class names that match a regex, that's the same.

But running two triggers for same class doesn't make sense to me.

Your user example, if you have additional per-class custom code.

I think option A would be best. Option B is in least favorable in my opinion.

Option a) and b) are equally restrictive. You may prefer a) because it works for your case, other may prefer b) for their case. The same with the order in c). The only practical option is d) in my opinion. Any idea how that can be made configurable?

[uzaysan]

You could just iterate through the schema and get all class names that match a regex, that's the same.

Yes. You are right.

Option a) and b) are equally restrictive.

I disagree. You can always put generic logic to class specific trigger. But you can't put class specific logic to generic trigger. If you do, it's not generic logic anymore.

The only practical option is d) in my opinion.

I would choose A. My logic is start from the small cluster and move to bigger ones. But If we really need to run both triggers I would let developer decide that.

Any idea how that can be made configurable

We already have validators. We can use that.

Parse.Cloud.beforeSave("Test", (request) => {
// do any additional beforeSave logic here
},{
    executionOrder: Parse.runThisOnly || Parse.before || Parse.after 
    // if its before execute  class specific trigger before generic one and visa versa and if user choose runThisOnly, we dont run generic trigger.
  }
});

We can use that. But its unnecessarily complex. Current solution works for old versions. And will work for newer versions. We can put documentation that" class specific trigger will override generic trigger " or something like that.

[mtrezza]

You can always put generic logic to class specific trigger. But you can't put class specific logic to generic trigger. If you do, it's not generic logic anymore.

Not sure I follow. My point is that you want the following rule:

• if a specific trigger exists, do not run the generic trigger

But someone else may want this rule:

• if a generic trigger exists, do not run the specific trigger

It may be a less common use case, but there may be scenarios in which this applies. For example if someone has a deployment in which Parse Functions load conditionally.

I think we need such a decision path logic anyway, because you can have multiple generic triggers that overlap.

Parse.Cloud.beforeSave("Test", () => {
});

Parse.Cloud.beforeSave("T.*", () => {
});

Parse.Cloud.beforeSave(".*", () => {
});

Which one should be executed?

In my opinion all, the question is just in which order. The developer just has to understand that the class name allows regex, that would be the only change in the docs.