-
Notifications
You must be signed in to change notification settings - Fork 17
Description
In some scenarios, we may want to be able to initialise a to parameter in an ETL rule. For example, if we have an abstract supertype Coin and two concrete subtypes GoldCoin and SilverCoin, we may want to have one rule that transforms a Score into a GoldCoin or a SilverCoin depending on the information of the Score.
Current behaviour
At the moment, doing this would require using at least two rules:
rule Score2GoldCoin from s: Source!Score to c: Target!GoldCoin {
guard: /* condition to create a gold coin */
/* set details of c */
}
rule Score2SilverCoin from s: Source!Score to c: Target!SilverCoin {
guard: /* condition to create a silver coin */
/* set details of c */
}
We might have common information to set for all coins, so this might be further expanded to three rules with inheritance:
@abstract
rule Score2Coin from s: Source!Score to c: Target!Coin {
/* set common Coin details of c */
}
rule Score2GoldCoin from s: Source!Score to c: Target!GoldCoin extends Score2Coin {
guard: /* condition to create a gold coin */
/* set GoldCoin-specific details of c */
}
rule Score2SilverCoin from s: Source!Score to c: Target!SilverCoin extends Score2Coin {
guard: /* condition to create a silver coin */
/* set SilverCoin-specific details of c */
}
Desired behaviour
It would be good to support a syntax like this:
rule Score2Coin
from s: Source!Score
to c: Target!Coin = condition ? new Target!GoldCoin : new Target!SilverCoin
{
/* set common Coin details of c */
if (c.isKindOf(Target!GoldCoin)) {
/* set GoldCoin-specific details of c */
} else {
/* set SilverCoin-specific details of c */
}
}
In general, we would extend each element of the to list with the ability to have an optional initializing expression, which would be executed during the first phase of the default ETL algorithm, before rule bodies are run.