Le 10 oct. 2017 à 16:52, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
> I was explaining to you the design. I thought it was the only way, but the only way
in my logic, whereas other may exist ;o) So perhaps your idea of overwriting the methods
can be good. But it has to be done.
If nobody see a problem with my logic I am willing to do it.
> I currently don’t know what is the behavior of ask the incoming association to an
entity that has none.
> I think that it can be good that you investigate this point before doing any change.
And then consequently modify the code to correct or not this behavior. It can be here an
error in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result.
Is it the expected behavior? Or do we want that we are not able to ask for outgoing
association if the entity is not source of an association. So for example, instead of
looking for outgoing association of a never source entity, it directly returns an empty
result. Perhaps we could have gain in performance, but be careful with the recursive
query. Indeed, it is not because an entity is never a source that its children are not. So
I don’t know but perhaps we can think to the question before changing.
> But perhaps also for performance reasons, it can be good, that such query can not be
asked to associations. Because here you know that in any case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
Sorry, I am not familiar with shouldNotImplement. If it does the job, why not.
> If you can modify the code to have the same behavior (or better), no soucy for me.
Just be aware of all of this (what was not the case initially). I think it is all the
reasons explaining the design. But perhaps I forgot some :p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Wait, one question, that I have and I don’t remember the answer. Why FAMIXNamedEntity is a
user of TOODependencyQueries and not of TDependencyQueries and thus why not just FAMIXType
is a user of TOODependencyQueries? Depending on the answer to this question, you can push
up TDependencyQueries or TOODependencyQueries to FAMIXEntity.
Thank you for the informations! :)
It was my pleasure :)
> Moose-dev mailing list
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Moose-dev mailing list