A way to query all relations for a given element

Completed

Comments

14 comments

  • Avatar
    Karl Hertz

    I support this one. We currently have the same need and our work around is fairly "heavy" for the db:

    Starting from "everything", WHERE relationship target (and/or source) is ONE OF "element"

    will return all relationship elements and from there you are able to get source or target...

    However this doesn't give us the ability to ask things like "which relationships types from an element is empty" or the like which would be very handy when checking for compliance. Extending the querying capability to be able to determine these things more easily would be very useful when looking at completeness for models - e.g. "Show me a red dot if there is nothing in relationship A, B and C for element X", has me doing things along the lines of building out three querys which I then combine with Join-queries and then I can use them in a smart column. It would be much easier for me to go

    Starting from element X

    Find all relationships and reverse relationships WHERE relationship type is ONE OF A, B, C

    I don't know if this is in line with the intent of the original request - if not, let's call it my added perspective.

    0
    Comment actions Permalink
  • Avatar
    Rune Kjerulff

    Thanks for the comment and elaboration Karl. I agree with all your points, and I have prebiously had issues along the same lines, somewhat different workarounds though.

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi, I'm trying to get a grip of your requirement(s) here. If I have read it correctly then the above mentions:

    1) A new block to 'find all relationships where I'm the source/target'

    2) An extension to the 'find relationship' block which allows you to select multiple relationship types.

    3) Returning relationship type elements from a Query? (I'm hoping I've misread that!)

    Note that there is also the option to start from a list of relationship types (similar to 'starting from everything', but more constrained).

    Could you confirm which of the above you are asking for (or something else entirely!)

    Matt.

    PS 

    Starting from element X

    Find all relationships and reverse relationships WHERE relationship type is ONE OF A, B, C

    Can be implemented as:

    Starting from everything

    where relationship source = X OR relationship target = X

    and type is one of A,B,C

     

    0
    Comment actions Permalink
  • Avatar
    Rune Frits Kjerulff

    Hi Matthew

    First of all thanks for getting back to me on this one so quickly.

    As you mention there's currently a workaround available that involves querying from the relationship element found using everything and then having that list of elements filtered by including a where relationship source/target filter, automatically excluding any results that aren't a relationship element.

    Using this workaround it's possible to get the information I'm after, but it can get a bit confusing to work with when you drill down through several levels of relatedness, moreover the query only understands the level it's currently on so the only place i can extract information about how A relates to B is on the relationship element A-B but i'd never want to expose the relationship element to the end user, so the queries can get pretty complicated.

    Basically the point issue I'm trying to address is that MooD doesn't leverage the capabilities it has as a highly denormalized database, in the possibilities it offers us in the configuration layer. Whenever you examine an Element in BA, you can see dependencies as a generic list of elements that the given element either relates to or that relates to it. It would be really great to have similar query features rather than having to configure everything as A->B or Joined query A->B, A->C,A->D.

    An expanded joined query functionality that would allow us to select relationships as well as queries would be helpful, as it removes the step of needing to define a bunch queries where the only purpose is to simply find the given relationship, but the real solution would be to have a generic option that finds all related elements, and if it's a new block then in that block having the option to filter by relationship type.

    Regarding Element type. What I'm lacking is the possibility to work with/display element type for relationship elements. I'm not talking about returning Element type as the result of a query, I'm talking about outputting it for display purposes, just as you do with Element type for normal Elements. The actual use case would be to be able to output it in smart columns, graph tooltips, matrices, and so forth. For instance between an Application Type and a Person Type, I might have 8 distinct relationship types, showing a graph that lists Application A relates to Person A, B, and C is largely useless if I can't show that Person A fills this specific relationship, and Person B fills this specific relationship. Again I do have a workaround, but it would be preferable to use built in functionality rather than Database query hacks.

    Would be happy to show you in practice some of what I'm trying to accomplish if that helps.

    Br

    Rune

    0
    Comment actions Permalink
  • Avatar
    Karl Hertz

    Hi Matt,

    Thank you for the quick answer!

    After reading Rune's answer, I think we are on the same page here. It's not so much that it can't be done, it's that it is fairly unintuitive to figure out how to do it (if I am interpreting your post correctly, Rune?).

    Regarding the requirements:

    1) A new block to 'find all relationships where I'm the source/target' - from my perspective, yes.

    2) An extension to the 'find relationship' block which allows you to select multiple relationship types. - from my perspective, yes, with the caveat that we would like to select those relationships with multiple options (e.g."where the relationship is empty", "where the relationship type is - or is not - of certain types). There is also a bit of a usability issue here - if I have in the range of 50 relationships from and to an element type, I don't want a tick list (or the like) where the assumption is should select all relationships I am after. I want the functionallity to be "find all relationships to/from element(s) WHERE ..." not "find relationship types A, B, ..., N".

    3) I would be fine with it returning either all elements from all the selected relationships from the element with the option of selecting the relationship elements instead (as per "normal"), or just returning the relationship elements as they are. It would be good to have a way to return "source or target WHERE element IS NOT [the starting element of the query]" (if that makes sense - I want to return all the things that isn't the element we started out with, since I won't know if the source/target query will return the related element or the element we started out from in a "neater way" than writing a separate query for this - which is what we use now).

    Finally, the query structure you wrote out in your response is what we are using at the moment. However, we are seeing performance issues with it particularly when working with MBA. A model using this structure can take more than half a minute to load from server and if you flip and flip a panel back with this information, it takes another twenty seconds...

    So, to sum it up, what I am after is:

    1. A more intuitive way of querying the database for something that comes up at a fairly regular basis - all the relationships to and from an element which meets certain criteria - has element, doesn't have elements, is of a certain type (when there is more than one) and so on without having to rely on understanding "the underlying structure of MooD" - e.g. "If I was to take everything in the DB and then I ask the DB for all the relationships in the DB which has the element as source or target, I would get all the relationships from/to the element" - it is not a case of "it doesn't work" it's a case of "I need to have a fairly deep understanding of how MooD works to get to this solution".

    As an example of another case where MooD lets us do things "in an easier manner", look no further than the regular relationship blocks. We could always get the same results if they returned the relationship elemenets and we then specified that what we were actually after was the target or source - but the way it works now where you have to "tick the box" to get the relationship elements makes it much more intuitive to work with MooD...

    2. Preferably an implementation which is not as "heavy on the database connection" as the current way of getting the data seems to be.

    I hope this makes sense...

    Karl

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi, an update on where we are with this:

    You should already be able to show the type of a relationship by returning the intermediate relationship element and then selecting the Element Type system property.

    We have changed 'Joined Queries' to be 'Combined Blocks': you can now select any block rather than only Queries, see the GIF below. I would be interested in getting hold of a Repository where these constructs have caused performance problems? (Available in CR7)

    I'm still considering what to do about the 'all relationships' requirement.

    Matt

    1
    Comment actions Permalink
  • Avatar
    Karl Hertz

    Matt,

    This looks very promising. I'm hoping to get my hands on b82.03 in the upcoming days - I'll try to remeber to check whether this a) solves our problems and b) if it's a bit less heavy on the DB connection.

    Thanks!

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Unfortunately this improvement is in the (yet to be released) CR7, not in b82.03.

    0
    Comment actions Permalink
  • Avatar
    Rune Frits Kjerulff

    Hi Matt

    Thank you for the update. It looks really interesting, looking forward to exploring the feature when the new version drops.

    The key difference however between this and a generic query that finds all relationships is that the combined block you showed has to be continually updated and maintained as the meta model changes and one might want to include additional element types.

    What i'm seeking to accomplish with a "Find all relationships" like query is to have generic model masters, charts, and diagrams that work for any and all element types in the repository, and where i can define other simple rules to exclude certain element types from the results of the query.

    I'd be happy to show you a practical implementation in a repository if you can find the time.

    Br

    Rune

    0
    Comment actions Permalink
  • Avatar
    Karl Hertz

    Matt, Rune,

    I agree with Rune's point. I read the names of the relationships wrong and got the impression that these relationships were actually some sort of typed thing. For some reason I thought "aggregates" were a new way of finding "everything" in terms of relationships, and "access" was everything that went "in" from other things. Anyway, apologies and, as Rune said - still need to find relationship, regardless of how meta model changes, preferably with an operator which doesn't take 30+ seconds to execute in MBA..

    /Karl

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi Karl and Rune,

    I've been looking in to this and deciding whether 'find all incoming relationships' / 'find all outgoing relationships' should be added to the Miscellaneous section of the Find Block picker. My only worry is that this may be an edge case which might not be used by many people. I've also thought of a better way to implement what you need with the build you have:

    First define a Query: All Rels
    Starting from everything where relationship source is not empty

    Then create this one. You can skip the last step to keep the 'element relationship' elements if you need to show the relationship type in e.g. a Data Sheet Matrix.

    0
    Comment actions Permalink
  • Avatar
    Karl Hertz

    Thanks Matt,

    To add some more clarity to the discussion: For us, I think the primary usage for this kind of construct is maintaining the meta model and in some cases, feeding graph panels which displays "complexity" or "completeness".

    "Edge case" might have different meanings. It could be that we are few who has this need right now (and that is what we mean by "edge case"). However, as with many other things, if I run into a problem, my first instinct is to try to resolve it with the tools I have available. It could well be that there are others which have run into a problem where this kind of query block would have been ideal, and they have worked around it and found (less elegant/harder to maintain/...) solutions. In this sense, it becomes something which looks like an  edge case but which is, if it had been part of the application, would be widely used...

    Just my perspective/two cents :)

    /Karl

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi,

    We have managed to fit in the new find blocks for the next release (CR7). Note the 4 new blocks in the image below.

    Matt. 

    2
    Comment actions Permalink
  • Avatar
    Karl Hertz

    Thanks Matt, looks good!

    0
    Comment actions Permalink

Please sign in to leave a comment.