Reify type declarations as associations about famix

[NicolasAnquetil]

description of the issue?
Not clear what is meant

[jecisc]

This was to reify type declarations as associations

[NicolasAnquetil]

Ah yes. Reification is needed. But creating an object for this could be costly in memory.
In the old query system, the queries created "fake reification" on the fly.
This could be a better solution ?

[jecisc]

The problem is that the MM does not know about this dependencies and we have to introduce a lot of hack in the query system of Moose in order to be able to query those relations. I don't think the memory we save is worth the extra complexity it brings.

[anneetien]

I don’t understand why we should add a lot of hack in the query system. The idea is to say that if we have an attribute a of type A, there exist an association between a and A where a is the source and A the target. In that context, Moosequery should work. Where is the problem? Anne

…

Le 14 mai 2020 à 18:38, CyrilFerlicot ***@***.***> a écrit : The problem is that the MM does not know about this dependencies and we have to introduce a lot of hack in the query system of Moose in order to be able to query those relations. I don't think the memory we save is worth the extra complexity it brings. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7WQ62SLQBEAP42NI23EDRRQNABANCNFSM4KOJA5EQ>. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572", "url": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[jecisc]

Since they are not reified as an association, the meta description does not know it is an association, there is no 'source' or 'target' and thus we need to search for them by hand, add them to the query results etc.. This makes the code of Moose Query more complexe and we cannot do everything we can do with other associations with type declarations since they are not reified.

[jecisc]

Another example of a problem caused by the fact that it is not reified is that it will not be possible to create navigation queries on them with the query model Clotilde is doing.

[badetitou]

I know we can have hacks etc.
But it is a bad idea because it will certainly introduce bugs.
So reify type declaration looks like a good idea for me too.

Sometimes it is interesting to not use association, but we have to be sure at 100% that we will not need them with Moose Query.
IMO it is only for users models and not the one we proposed.

[anneetien]

I think it was the point of the issue to replace them by association ;-) Anne

…

Le 20 mai 2020 à 13:49, CyrilFerlicot ***@***.***> a écrit : Since they are not reified as an association, the meta description does not know it is an association, there is no 'source' or 'target' and thus we need to search for them by hand, add them to the query results etc.. This makes the code of Moose Query more complexe and we cannot do everything we can do with other associations with type declarations since they are not reified. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7WQ5ARYZ432T5RED6FH3RSO7V3ANCNFSM4KOJA5EQ>. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073", "url": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[NicolasAnquetil]

May be we can do it without reifying the dependence and without creating a hack to?

We decide that dependence is a strong "property"that we want to be able to always compute.
(seems a reasonable assumption to me)

We create "marker"of relations (in the sense of FamixMetamodelGenerator>>defineRelations) that create depedencies.
e.g. (tTypedEntity property: #declaredType) isDependency

(note that all properties are not dependencies even if they have opposite entities, e.g. comment are sourceAnchor are not)

then we change queryOutgoingDependencies to collect all these relations.
The from is the entity having the relation, and to is the entity in the property.

That would solve moosetechnology/Moose#2303 and moosetechnology/Moose#2304 also

[NicolasAnquetil]

Note: this could imply

• either generalizing MooseQueryTypeDeclarationAssociation which is specific to the declaredType property
• or removing it because we would allow non associations to deal with the isSource / isTarget mechanism
• or may be a bit of both

At this moment in history, the 2nd option looks like the most promising, least disturbing to me

[NicolasAnquetil]

First analysis, possible steps :

• look at TEntityMetaLevelDependency>>dependencyFM3PropertyDescriptionIn: so that it returns all properties that relate to other entities (relations in FamixMetamodelGenerator parlance)
• review the isSource / isTarget mechanism so that for these properties we can define the owner as source and the content as target (whereas associations have 2 properties one being the source and the other the target)

[anneetien]

It seems that the relationQuery have solve this issue.
What do you think @badetitou @NicolasAnquetil?
Can we close this issue?

[NicolasAnquetil]

No, I think it is still on the table:
by relation query you mean FamixQueries (I hate this name), the model behind the MiQueryBrowser?

If so, then the problem is solved for the MiQueryBrowser, but not for the MooseQueries, the API used by programmers.
And we still need this API because we cannot do everything with the queryBrowser.

Any opinion on introducing a new dependency marker in the builder to mark relationships that introduce dependencies (see comment #121 (comment))?