Hi,
Le 12 oct. 2017 à 10:55, Cyril Ferlicot cyril.ferlicot@gmail.com a écrit :
Hi!
Sorry for my previous incomplete mail. I missclicked. Here is the full one:
I have some improvements I would like to make to Moose query and I would like your approuval.
First. Currently there is:
- #queryAllOutgoing and #queryAllOutgoingAssociations to query all the
outgoing associations of the receiver
- #queryAllIncoming and #queryAllIncomingAssociations to query all the
incoming associations of the receiver
#queryAll{Direction} is based on the meta-model properties while #queryAll{Direction}Associations seems to be more empirical.
See:
queryAllOutgoingAssociations ^ self queryStaticOutgoingAssociations addAll: self queryAllOutgoingInvocations; yourself
I propose two changes:
- Remove the empirical implementation to use only the one based on the
meta-model
- Deprecate #queryAllIncoming and #queryAllOutgoing. I think
#queryAllIncomingAssociations is a better name, but I can change my mine if you have a different opinion on that.
As far as I understood when we discussed in Maribore, it can be relevant to have specific associations to earn time. But perhaps cache can bring a solution. I don’t know if the solution you propose is time consuming or not.
Second. To query all the in/out associations with the method based on the meta-models, there is the use of "FAMIXAssociation withAllSubclassesDo:" to iterate on the associations and do the queries for all of them.
I agree with you, we need a method to compute the Association Types the class of self is source (rest. target) of. And not try all the association to know if the class is source or target of this association.
I have three problems with that:
- This is not efficient. If an entity can have only 2 incoming
associations it will still try the queries for all the associations in the image
- This has a role in the circular dependency between FAMIX-Core and
Moose-Query packages because we reference FAMIXAssociation
Moose-Query is already dependent of FAMIX-Core, no?
- If one day we create another project from FAME to represent
something that is not a software model, we will maybe not have FAMIXAssociation but we might still have associations. And Moose-Query could still be useful on this project.
I propose to add to TEntityMetaLevelDependency two methods:
allOutgoingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes) addAll: self outgoingAssociationTypes; yourself
I don’t really see how it works in practice. I think that #outgoingAssociationTypes is missing in your explanation.
#privateOutgoingAssociationTypes self allDeclaredProperties select: [ :fm3Prop | | ic | ic := fm3Prop type implementingClass. ic notNil and: [ic inheritsFrom: FAMIXAssociation ] ]
And here, I don’t manage the direction yet.
Why you don’t do the same thing than for allChildrenTypes?
Code is missing for me to fully approve what you are doing.
In other words: 1. I agree about the idea that we have to compute for each metaclass its incoming / outgoing associations 2. I am not enough data to approve your code 3. you can come on Friday morning to the Moose Dojo and Pharo sprint to make the changes together if you want.
Anne
and
allIncomingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes) addAll: self incomingAssociationTypes; yourself
Thus the entities will be able to return the associations they and their children can have.
Then we can replace "FAMIXAssociation withAllSubclassesDo:" by "(self strategy allAssociationTypesFor: anEntity) do:" where the strategy is a MooseQuery{Direction}DirectionStrategy that will call either #allIncomingAssociationTypes or #allOutgoingAssociationTypes.
I have an image with all those changes and all the tests of Moose-Query and Moose-Chef are green.
I am waiting your opinion on this changes.
Have a nice day.
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev