Starting From All Primary Elements
As a Solution Builder
I want to be able to configure the query builder to "Starting from all Primary Elements"
So I can find all Primary Elements instead of "everything", because it is the more common use case
The benefits are the query will run faster and I will not have to remember to re-configure the query every time a theme or type is added
Acceptance criterion is that the query builder, which is use in all queries, smart columns, and matrices, can be configured to "Starting from All Primary Elements" so that the result is all primary elements
Priority is low
-
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.
-
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
-
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
-
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
-
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.
-
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.
Please sign in to leave a comment.
Comments
15 comments