Starting From All Primary Elements

Comments

15 comments

  • Avatar
    Matthew Dodd

    I always worry when people start from everything, we have even toyed with the idea of removing the option.

    Is there some data logic to WHY you want to start from all primary elements which we could use as a starting condition?  As a user the concept of a primary element is hidden and the difference between a process / object / PE / whatever is not obvious?

    You could always limit it to hierarchical elements by adding "where parent is empty OR where parent is not empty"!  Another option could be to write a smart column with a custom function fact which checks if the ID exists in the PE table (happy to walk you through this if it's something you'd like to pursue?)

    This isn't a hard option to add but I don't want to add it if this is a problem specific to you. It also adds a new concept to the user which is very much a technical detail.

    Matt.

    1
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Hi Matt,

    I find it difficult to follow the template and include the WHY. Perhaps this is missing from the template or I have misunderstood the template.

    I am also sceptical about queries that start from everything, nonetheless I find myself using them. Two examples are:

    • A pick list smart column, where the result is "no colour" or "read-only colour", used to conditionally colour e.g. matrix columns so the web-user can visually distinguish read-only and editable data.
    • A simple smart column, where the result is the element name, used as virtual element name field in contexts where the system field is not available.

    Both of these examples are to compensate for other shortcomings in MooD that should be fixed instead. I guess this is why I set the priority to low.

    I'll post an update if I encounter some better examples.

    -Peter

     

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    I remember another example, where I need to find all primary elements.

    Mistakenly we sometimes create models on elements that use model masters. So, we need keep track of elements with unwanted models. There is no built-in query functionality to find elements with models, so I have to create a database view, expose it as a data table, and create a query that use the data table elements to find the corresponding repository elements based in the system id. This query starts by finding all primary elements.

    Again, this is an example where I compensate for other shortcomings in MooD.

    -Peter

    0
    Comment actions Permalink
  • Avatar
    Kevin Bedward

    Thank you for taking the time to share more on this topic Peter.

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    You could use a custom function fact instead of a data table? (I realise this is still not perfect but less hassle than a data table)

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    That is certainly a possibility, and it is simpler than what I do now. Only reason I ended up with the solution I have now, is that I started with a SQL query to find all primary elements with models.

    If I use a custom function fact, the source query still needs to by "Find all Primary Elements".

    -Peter

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    I have just converted one of our solutions to use the custom function fact. It works a lot better and faster. Thanks for the suggestion.

    However, as I also wrote above, I still use a source query the finds all primary elements.

    -Peter

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    BTW you could speed it up further by adding a Fact Filter of "Where count of models > 0" (So you return far fewer records from the database)

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Did that. The repository has little under one million primary elements and about 500 elements with models.

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi, as of build 43 you could use the following to start from object/process/primary element aliases:

    Starting from everything

    where parent contains IGNORE VARIABLE

    and has model is IGNORE VARIABLE.

     

    I realise this is a workaround but at least the list of types will expand automatically over time.

    Matt.

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Not sure I understand, but I'm looking forward to seeing it. Thanks!

    -Peter

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    Hi, so you start from everything which includes everything..

    Then you say 'where parent is variable IGNORE' which reduces you down to all hierarchical aliases.

    At this point you need to remove Epochs / Epoch Groups from the list of types so

    'where has model is variable IGNORE' results in all all objects/processes/primary elements. 

    I imagine you have NO objects/processes so you have the query you want.

    Clear as mud?

    Matt.

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Clear as crystal?

    It that efficient? If we are just hacking an empty first block, I would think it is easier and more efficient to do "Starting from elements" and then leave the element input empty.

    -Peter

    0
    Comment actions Permalink
  • Avatar
    Matthew Dodd

    It turns out to be efficient yes. Ignored conditions don't produce any SQL but they do affect the tables/aliases we consider.

    "Starting from elements variable IGNORE" would result in your whole rep, not just primary elements?

    Matt.

    0
    Comment actions Permalink
  • Avatar
    Peter Kristensen

    Sorry, I confused this issue with another issue. Please ignore my previous comment.

    -Peter

    0
    Comment actions Permalink

Please sign in to leave a comment.