2. Known Issues

Problems with time-variable attributes

Some attributes can be defined in a way that causes them to change over time. What is meant here is a change that occurs when the attribute is constructed repeatedly, for instance

when a global attribute is constructed (during the startup procedure when the Xplain backend is started),

when a session attribute is constructed (when a user logs into the system),

when an attribute is constructed (global or session-local) due to loading a saved analysis.

Usually, the parameters of the attribute to be constructed precisely define the hierarchy of states that are available afterwards, but sometimes it is convenient to adapt this hierarchy to certain parameters like the current date and time. In particular, this happens very often to attributes that themselves represent things like a date or a certain age or time span.

An obvious example is an analysis based on actions (prescriptions, sales, etc.) currently residing in the database. It is clear that there are no entries for the future yet in the database, so it wouldn’t make much sense to list the months of the next 10 years in a date-attribute to be used. Hence the attribute is constructed in a way that only fixes the first month to be listed, say January 1980, and to extend the list of available states to the current month or maybe the last month of the current year. If such a configuration is stored (in a startup configuration file or in a certain analysis or session file), it will cause the construction of a different attribute if “the same” attribute is constructed again one or several years later, since this attribute will contain further refined states for additional months and years. (The same applies to age attributes, but here the set of states stays the same while the reference year/date changes.)

This behavior can result in an error if the user is loading an analysis that was saved while using an older instance of an attribute. In particular, an error occurs if the stored analysis refers to a state of the attribute, that does not exist any longer because the state hierarchy changed. Consider for instance the situation where the user performed a selection of the “last” state of the state hierarchy in a date attribute that was created in the year 2020. We assume that this date attribute consists of several levels like years, quarters, months, and so on. This detailed hierarchy ends at December 31, 2020. Hence the last state of this attribute represents all dates from January 1, 2021 ad infinitum. Maybe the name of this state is “[2021-01-01,oo[“. If this state is listed in a selection, this stored analysis will cause an error if it is loaded one year later, because then there will be states for the months in 2021 and there will be no state representing the time interval from January 1, 2021 ad infinitum. The last state might now represent all dates from January 1, 2022 ad infinitum, i.e., its name could be “[2022-01-01,oo[”, while all dates of 2021 might be represented by the state “[2021-01-01,2022-01-01[“.

Fortunately, it doesn’t usually make much sense to select the last state of the hierarchy explicitly. Actually, all cases that would lead the user to select this state have a different semantics. Usually, the goal is not to select this particular special state “[2021-01-01,oo[”, but to select all states representing values from January 1, 2021 ad infinitum (or more generally above a certain threshold). Anyway, this kind of threshold or range selection is NOT YET POSSIBLE in Xplain Data’s system, but it is one of the features to appear in the near future.

As long as this new kind of functionality is not yet available, there are some workarounds that can be applied to circumvent/fix this problem:

Provide a fixed end for the date attribute right from the start. (The problem does not occur, but: the date hierarchy does not adapt to the future.)
For attributes created without fixed end date, introduce the fixed end afterwards. (The occurring problem is fixed, but: the date hierarchy does not adapt to the future.)
For attributes created without fixed end date, fix the deprecated selection state. (The occuring problem is temporarily fixed, but might appear again in the future.)