Feature request: DEFAULT SRC/TGT atoms for RELATION statement #1189
Comments
|
@hanjoosten, what do you think? Any idea about implementation effort? I think the output is best added to the relations.json like this: {
"affectedConjuncts": [],
"inj": false,
"mysqlTable": {
"name": "ProjectMembership",
"srcCol": {
"name": "ProjectMembership",
"null": false,
"unique": true
},
"tableOf": "src",
"tgtCol": {
"name": "tsAdded",
"null": true,
"unique": false
}
},
"name": "tsAdded",
"prop": false,
"signature": "tsAdded[ProjectMembership*DateTime]",
"srcConceptId": "ProjectMembership",
"sur": false,
"tgtConceptId": "DateTime",
"tot": true,
"uni": true,
"defaultSrc" : null,
"defaultTgt" : "{EX}{php}date(DATE_ISO8601)"
},See fields |
|
This is an interesting idea. However, since it is an addition to the syntax of Ampersand, we have to be careful. In general, syntax is added easily, but removal of it is hard. That said, here are some initial thoughts about this proposal:
|
|
While I can see that this could be useful, I'm not convinced that this is a serious problem. Of course, there is additional queries and boilerplate code here, but if that is going to be a real problem, then my guess is there are lots of other problems as well. More to the point perhaps, it isn't clear (yet) what 'DEFAULT' means.
Also, default values are not always that simple. Consider the following: Here, initialization of I would much rather have EQV constructs (I'm sure there has been an issue for this but I cannot find it any more), which computes the value of a relation as the contents of an expression, e.g. |
|
@hanjoosten, you're right, I made a mistake, the line I meant is: |
|
@RieksJ, I think you are missing the point here. It is not about when RELATIONs are populated, but how to populate certain relations when either the src or tgt atoms are inserted in the CONCEPT population. I recognize that the default values are not always that simple; for situations that require a more complex expression, the regular way using the exec-engine still works. In reaction to specific questions:
I think we shouldn't allow expressions, only atom values (singletons) or TXTs that can be processed by backend (incl. exec-engine).
DEFAULTS as I propose them now are directly inserted after inserting a new atom. |
|
Thanks for clarifying. I'm still not convinced though that the benefits of having it outweigh the trouble of implementing and maintaining it. I'm also not sure I understand the actual problem that you are trying to solve:
I'm curious to find out what @stefjoosten and @hanjoosten have to say about this, as they are the ones to decide what they do (not) implement. |
|
@RieksJ, I guess that the issue you couldn't find is #311. The value of that issue is higher than this issue, however, the estimated implementation effort is much higher as well. |
|
Having defaults at the frontent level is a great idea and that's also where they belong. I predict that we'll want different defaults for different interfaces soon, but that's all to be part of #311 and this could be a more manageable small step. For syntax, I observe that this ties to the TOT (or SUR) rule that is implicitly created in the declaration of the relation. One could imagine having some notation to indicate which atoms to use for any existential quantifier (the implicit \exists that arise at ;), but that would be a big step instead of a small step, seeing this work first might make it easier to think of how to do that big step too. I also have no idea on how to make the connection with the TOT rule more visible in the syntax, so I'm happy to go with what is proposed. |
|
Since default values are going to be simple values, we could perhaps go for syntax such as Syntax such as |
|
Glad you give the syntax some thought too. However, the place you suggest for the default values is a list of properties, which in fact are restrictions on the population of the relation. The default values for atoms are something else. So we start with the keyword "DEFAULT". this will be followed by an optional SRC part, then an optional TGT part. After the keyword we will expect either:
Some examples: notes:
|
|
I know that the place I suggest is in the existing list of properties, thereby following up on the remark by @sjcjoosten who stated that having a default value implies such properties. If (not saying: 'when') we follow up on that remark, would it make more sense to consider syntax such as I appreciate that having separate syntax as you suggest is easier to implement, and that could be a valid consideration too. |
|
Ah, good point. I didn't get that before. If we go this way, it seems to me we could also skip the keywords Notes: The value given with TOT is by definition meant to populate the target concept, and the value given with SUR is by definition meant for the source concept. Hence, there is no need for a specific keyword. I like this idea. What do @Michiel-s, @sjcjoosten, and @stefjoosten think? |
|
I am not sure about the amount of work of implementing Rieks's idea vs my initial idea. I will give that a thought, but beside of that, I would like to know what the others like most. |
|
What I like is that this ties in very well with the UNI/TOT rules. I also very much like changing the prefix "{EX}" within the string to a keyword EXEC. What I dislike is that it encourages defaults to be specified at the place in the script where RELATIONs are declared: the conceptual model is conceptually far away from tweaking interface behavior so it would be nice if the syntax would naturally separate the two as well. If I as a modeler decide to change a relation to no longer have TOT, I'd like to see a warning/error about the DEFAULT rule I wrote in another file (and not have a DEFAULT rule add the TOT property back because of syntax). Given these likes and dislikes, I'd say let's go with the EXEC idea regardless. Apart from that, the two are about equal to me. |
|
This issue very much relates with the implementation of the ENFORCE statement (Issue #1204). This is currently in the review phase, and I expect it to be into development shortly. @Michiel-s , Do you think such syntax will solve your original problem? |
|
Just for a reference, I now think the syntax boils down to: Property
::= ("SUR" | "TOT") ( '<AtomValue>' | "EVALPHP" '<DoubleQuotedString>')?
| ("ASY" | "INJ" | "IRF" | "PROP" | "RFX" | "SYM" | "TRN" | "UNI") Which can be visualized as Some notes:
|
|
I just had a chat with @stefjoosten . He suggested to enable the use of an expression, at the place where the atomvalue can be given. So we still need some more thinking of the syntax. |
|
I like the idea of allowing an expression in the place of Property
::= ("SUR" | "TOT") ( '<AtomValue>' | "EVALPHP" '<DoubleQuotedString>')?
| ("ASY" | "INJ" | "IRF" | "PROP" | "RFX" | "SYM" | "TRN" | "UNI") (Han's earlier proposal) and: Property
::= ("SUR" | "TOT") (Expression | "EVALPHP" '<DoubleQuotedString>')?
| ("ASY" | "INJ" | "IRF" | "PROP" | "RFX" | "SYM" | "TRN" | "UNI") then the second would subsume the first. We might be inclined to think that building the first of these two will not hinder us from ever building the second of these two. That suggests, however, that the type of Expression and the type of For The generalization of |
|
Cool! But what happens when |
Good question! I can think of only one kind of behavior, which is consistent with what the exec-engine would do: both defaults would get inserted. If |
|
I agree that this should be the behaviour. Regarding error messages, I can see that in an implementation, such exceptions could somehow be caught and the necessary guidance for helping out the developer out could be added. One way would be to handle ENFORCE statements (and thereafter any associated UNI/INJ checks - but also any SUR/TOT checks, because there is also no guarantee that there will be a TGT atom - in a designated context (we used to call a SERVICE), which has its own execengine run and error message generation. |
|
@sjcjoosten, good point, allowing an Having said that, there is more to think about w.r.t. the Property
::= ("SUR" | "TOT") ( "VALUE" '<AtomValue>' | "EVALPHP" '<DoubleQuotedString>')?
| ("ASY" | "INJ" | "IRF" | "PROP" | "RFX" | "SYM" | "TRN" | "UNI") which can be visualized as |
|
I suggest |
I was thinking of this when I wrote that the generalization of |
|
@Michiel-s You have been quiet for a long time. Do you think this is going the right way? |
|
@RieksJ wrote earlier:
This is done! See issue #1204. It is in development, will be released next friday. |
|
|
@Michiel-s , I realized that the violation itself will probably be required, as well as the fact that in these cases there must be a |
This is a comment regarding #1204 I think. Not for here |
I really like this. I still have to take a look at the generated output in json files and implement the prototype framework part. |
|
Ok, I just had time to start implementing this feature in the prototype framework, but I conclude that we are not there yet for the compiler part. Some rework is needed:
@hanjoosten, regarding 1, I took a look at the code changes in #1210 and noticed that you indeed coupled the default value to the property definition, that's why there are also so many code changes: type AProps = Set.Set AProp
data AProp
= -- | univalent
Uni
| -- | injective
Inj
| -- | surjective
Sur (Maybe APropDefault)
| -- | total
Tot (Maybe APropDefault)
| -- | symmetric
Sym
| -- | antisymmetric
Asy
| -- | transitive
Trn
| -- | reflexive
Rfx
| -- | irreflexive
Irf
deriving (Eq, Ord, Data, Typeable)I think this is not a good design decision and propose to undo this. I would say to couple the default src or tgt value to the |
|
I think we all didn't understand your feature request. In the middle of the discussion you probably missed out. So let's see what can/should be done now
|
{
"affectedConjuncts": [
"conj_54",
"conj_56"
],
"defaultSrc": "AAVString {aavhash = 723817982351009968, aavtyp = OBJECT, aavtxt = \"test2\"}",
"defaultTgt": "AAVString {aavhash = -4513705105538940906, aavtyp = OBJECT, aavtxt = \"test\"}",
"inj": false,
"mysqlTable": {
"name": "r",
"srcCol": {
"name": "A",
"null": false,
"unique": false
},
"tableOf": null,
"tgtCol": {
"name": "B",
"null": false,
"unique": false
}
},
"name": "r",
"prop": false,
"signature": "r[A*B]",
"srcConceptId": "A",
"sur": false,
"tgtConceptId": "B",
"tot": false,
"uni": false
}, |
|
Proposed syntax: |
|
Not to forget the minor bugs:
|
|
Recap: I had a call with @Michiel-s today. Now I understand that this issue is NOT about automatically fixing violations. That would limit the scope of the feature to TOT and SUR relations. As he explained in his comments from yesterday and today (see above) the idea is to have a default value filled in in the backend, outside of the execengine. That's all. To do this, the following has to be done:
It currently is: which can be visualized as The proposal is to add an optional default after the optional which can be visualized as The which can be visualized as |
|
Hi @hanjoosten, I'm currently testing feature branch Feedback
Line of reasoning for syntaxE.g. this script is how it now looks like: Somehow to me the part My suggestion is to add the keyword DEFAULT: Using newlines this can look like: This reads like "the default target value is ..." or if multiple, "the default target values are ..." Furthermore I propose to add a comma ProposalThis results in: and Help@hanjoosten, I tried to edit the parser myself to demonstrate what I propose, but I got stuck hopelessly. Really need your help, but I do want to learn. |
|
@Michiel-s , No sweat. This will be a relative easy change. It only affects the parser and prettyprinter. I would gladly help you do this yourself, during a pair programming session. |
Not sure what the meaning is of two defaults? I get how a project can get two statuses, so the example clarifies a lot, but my understanding is that If not, perhaps the syntax could read |
|
The idea here is quite simple: Since the relation is not restricted to be UNI, why then restrict the amount of defaults to one? |
I agree with this point (I should argue that we might even want to allow the default to be defined as zero). I was merely proposing to use the syntax |
|
Ah, I see. That leads us to something like Defaults ::= ( 'DEFAULT'
( 'SRC' | 'TGT' ) ( 'VALUE' '<AtomValue>' ( ',' 'VALUE' '<AtomValue>' )* | 'EVALPHP' '<DoubleQuotedString>' )
( ',' ( 'SRC' | 'TGT' ) ( 'VALUE' '<AtomValue>' ( ',' 'VALUE' '<AtomValue>' )* | 'EVALPHP' '<DoubleQuotedString>' ) )* )?
|
|
I see what you mean. I edited above syntax. This leaves us with the name of the keyword There is no way that Ampersand itself knows what the result will be of the PHP expression. It could be a single atom, but it could be a set as well. @Michiel-s , can that become a problem? In any case, the modeler should know what she is doing. |
|
Yes no worries, if a eval returns a list, we have multiple defaults. I like the simpler syntax proposal by @sjcjoosten to specify multiple values. Great! |
My personal preference goes to DEFAULT (single). Because you default to a single or you default to a list of values. No need to specify plural option, which is not always, and most often not the case. Other argumentation is possible of course. I wouldn't allow both, that's only for those who can't come to an understanding and I think we can😁 |
|
Michiel said: "I think it is best to NOT add the specified atoms in the default statements to the default population of a script." |
I completely agree. I believe we may want to (at some point in the distant future) talk about having a certain default for one interface (which may be a set) and use a different default in a different interface. I'd want to use the word 'DEFAULTs' to refer to those cases (not as part of Ampersand syntax, but in the same informal way we can talk about 'POPULATIONs' when referring to all the different sources from which we get the initial population; Note that the POPULATION keyword is also singular) |
|
Thanks guys for this discussion. Now @Michiel-s can fix this ;) |
|
Minor change in syntax compaired to @hanjoosten's latest proposal, after discussion with @sjcjoosten because of ambiguously in look ahead after comma..
|
|
Fixed |
Context
Working with Ampersand prototype in practices, I recognize that often I add an exec-engine rule to fill a default tuple for a relation when a new src or tgt is instantiated. This holds in particular for reification of relations. Let me give an example:
Suppose I have a
membershiprelation betweenPersonandProject. Now I want to register theroleandstartdatefor thatmembership. What I do is I reify themembershiprelation into aMembershipconcept like this:And then I add the additional data requirements, like this:
Problem statement
A problem now is that I have to deal with the two new functional relationships and provide editable fields in the UI to allow for new ProjectMemberships to be created.
However, the start date can be filled automatically and the role can have a default value (e.g. 'Participant', 'Projectleader').
Then I create a new exec-engine rule to fill those in, like this:
This requires additional queries (=performance) to check/verify these rules and more boilerplate code in the ADL files.
Feature request
How about allowing to specify default src/tgt values at the relation definitions, e.g.
This means that when a ProjectMembership is instantiated, by default the pair ("","Participant") is populated in the relationship.
Both default SRC and TGT can be specified, e.g.:
In this case, additionally, if a new Role is instantiated, the Test project is bound.
Allow for defaults by the exec-engine
To support the case where the current date timestamp needs to be inserted, I propose to accept also TXT statements that can be parsed by the exec-engine just like with the rule violations. Like this:
Note the TXT in between. This is the same as we do in the VIOLATION and INTERFACES statements.
This allows for flexibility.
Considerations
The text was updated successfully, but these errors were encountered: