You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 supertypeCoin
and two concrete subtypesGoldCoin
andSilverCoin
, we may want to have one rule that transforms aScore
into aGoldCoin
or aSilverCoin
depending on the information of theScore
.Current behaviour
At the moment, doing this would require using at least two rules:
We might have common information to set for all coins, so this might be further expanded to three rules with inheritance:
Desired behaviour
It would be good to support a syntax like this:
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.The text was updated successfully, but these errors were encountered: