Temp View difference to Perm Views

Post Reply
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Temp View difference to Perm Views

Post by paulsimon »

Hi

We previously used code like this

IF( ViewExists( vCube , vView ) = 0 ) ;
ViewCreate( vCube , vView ) ;
ENDIF ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;
etc

This worked fine with permanent views, since if the view already existed the ViewSubsetAssign modified it as required.

However, this technique does not work reliably with Temp Views. It was a while before we spotted this as our Temp View names include a time stamp that goes down to seconds, so in most cases the view did not already exist. It was only when a series of calls were being made in a tight loop that we noticed a problem.

If using Temp Views you need to use something along the following lines

IF( ViewExists( vCube , vView ) = 1 ) ;
ViewDestroy( vCube , vView ) ;
ENDIF ;
ViewCreate( vCube , vView , 1 ) ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;

Regards

Paul Simon
miker100
Posts: 9
Joined: Mon Oct 26, 2009 3:42 pm
OLAP Product: TM1
Version: 9.1 SP4 HF2 x64
Excel Version: 2003

Re: Temp View difference to Perm Views

Post by miker100 »

Hi Paul,

I thought temp views and subsets only existed whilst the TI was running and there was no need to destroy them. I guess if you have a "permanent" view with the same name then maybe you do?

Cheers

Mike
tomok
MVP
Posts: 2831
Joined: Tue Feb 16, 2010 2:39 pm
OLAP Product: TM1, Palo
Version: Beginning of time thru 10.2
Excel Version: 2003-2007-2010-2013
Location: Atlanta, GA
Contact:

Re: Temp View difference to Perm Views

Post by tomok »

paulsimon wrote: Wed Feb 20, 2019 10:45 am If using Temp Views you need to use something along the following lines

IF( ViewExists( vCube , vView ) = 1 ) ;
ViewDestroy( vCube , vView ) ;
ENDIF ;
ViewCreate( vCube , vView , 1 ) ;

ViewSubsetAssign( vCube , vView , vMeasDim, vMeasSub ) ;
FWIW, this is exactly what I've been doing in all my TI's for a long time (except I just started using the "1" parameter in view and subset creates a couple of years ago).
Tom O'Kelley - Manager Finance Systems
American Tower
http://www.onlinecourtreservations.com/
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Temp View difference to Perm Views

Post by paulsimon »

Hi Mike

In this scenario we had a process that takes a parameter of an Entity and it is normally run directly from a web sheet. However, we sometimes need to do a bulk run for all Entities. To do that we have a master process that loops through a subset of Entities and calls the individual Entity process, passing in each Entity from the subset. Now, because the temp views are all being created within the scope of the same master process they seem to persist from one call to the next. That is why you need to destroy the temp view because there is a risk of clash even if the temp view has a name with a timestamp down to seconds since in some cases the process may take less than a second to run. This clash did not used to be a problem with permanent views, since the ViewSubsetAssign seems to modify the view correctly. However, it is a problem with Temp Views.

Regards

Paul Simon
Wim Gielis
MVP
Posts: 3105
Joined: Mon Dec 29, 2008 6:26 pm
OLAP Product: TM1, Jedox
Version: PAL 2.0.9.18
Excel Version: Microsoft 365
Location: Brussels, Belgium
Contact:

Re: Temp View difference to Perm Views

Post by Wim Gielis »

paulsimon wrote: Wed Feb 20, 2019 11:02 pm However, it is a problem with Temp Views.
Indeed. IBM should look into that because to me the temporary objects relate to the called process. Even if I call it 1,000 times, I don’t need/want to explicitly delete views and subsets - they’re temporary for a reason.
Best regards,

Wim Gielis

IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
babytiger
Posts: 78
Joined: Wed Jul 31, 2013 4:32 am
OLAP Product: Cognos TM1, EP, Analyst
Version: 10.2.2
Excel Version: 2013
Location: Sydney AU

Re: Temp View difference to Perm Views

Post by babytiger »

What I would do is, attached a random number (10 digits) to the view/subset name every time a temporary object is used. And I've removed the check and remove existing view/subsets (the chance of the same object name is used in the same process chain is pretty low). Since they are temporary objects, I don't have to worry about deleting them (even process fails).
MK
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Temp View difference to Perm Views

Post by lotsaram »

In my opinion the original implementation of temporary objects being only available to the immediate process which created them is seriously flawed and constitutes a product defect.

Temporary subsets & views being only available to the TI creating them excludes the possibility of a functional library being able to utilize temporary objects. So currently if you want to leverage temp objects all code to create and manage the subsets and views needs to be replicated in each and every process. This goes against every best practice principle for developing applications you can think of. Code is distributed not centralized, unnecessarily duplicated, more effort to maintain, multiple not single point unit tests. Suffice to say gets my goat.

A proper and correct implementation of temporary objects would have them available within the same TI "transaction" that is If one process calls a library function via ExecuteProcess which creates a temporary view, then the calling process should be able to use the view.

I remain very hopeful that this evidence of temp objects persisting beyond the creating process is actually evidence not of a bug but if IBM seeking to address the initial flawed implementation and do it properly.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
User avatar
Steve Rowe
Site Admin
Posts: 2410
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: Temp View difference to Perm Views

Post by Steve Rowe »

As ever the most right thing is to give the developer the tools to make the choice themselves of the scope of the object.
Flag values of
0 - Permanent object
1 - Temp and local to the creating TI only.
2 - Temp and global to the entire TI chain.

Note this is a suggestion, flag 2 does not exist
Technical Director
www.infocat.co.uk
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Temp View difference to Perm Views

Post by paulsimon »

Hi lotsaram

We are using PA 2.0.5. My understanding is that a temp view created in a master process is available to any process called by that process.

We have a case here where we use a generic process to transfer data from one cube to another.

The calling process first uses a temp view to clear existing data from the relevant area of the cube, it then creates another temp view to act as the source view and it passes the name of that temp view into the generic process as a parameter.

The generic process reads from the temp view passed in as a parameter to transfer data from the source cube to the destination cube. The main purpose of the generic process is to do some attribute lookups on the data as it passes through, because the target cube has more dimensions than the source cube.

Anyway this appears to work. We run daily checks to ensure that the two cubes are in step.

Regards

Paul Simon
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Temp View difference to Perm Views

Post by PavoGa »

I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.
Ty
Cleveland, TN
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Temp View difference to Perm Views

Post by lotsaram »

PavoGa wrote: Mon Feb 25, 2019 12:39 pm I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.
You mean using one subset as the base set for another? As in either ...
{FILTER( [Dimension].[Temp Subset], filter condition )}
or
{FILTER( {TM1SubsetToSet( [Dimension], "Temp Subset" )}, filter condition )}

If yes we have noticed that too but I put it down to "expected behavior". Easy enough to work around by reusing the whole MDX of the first subset and embedding it in the 2nd as opposed to trying to use the subset.

If that's not what you mean then probably others don't know either not just me.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Temp View difference to Perm Views

Post by lotsaram »

paulsimon wrote: Mon Feb 25, 2019 11:02 am We are using PA 2.0.5. My understanding is that a temp view created in a master process is available to any process called by that process.

We have a case here where we use a generic process to transfer data from one cube to another.

The calling process first uses a temp view to clear existing data from the relevant area of the cube, it then creates another temp view to act as the source view and it passes the name of that temp view into the generic process as a parameter.
That would be massive news. If it's true, quite nice of IBM to do it and not actually communicate the change! (Especially as there was an RFE for this which was denied.)
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Temp View difference to Perm Views

Post by paulsimon »

Hi Lotsaram

I am probably too stupid to realise that it couldn't be done and just went ahead and did it since it seemed like a logical thing to be able to do.

Anyway, I suggest you try an experiment yourself to confirm it.

Regards

Paul
User avatar
PavoGa
MVP
Posts: 616
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Temp View difference to Perm Views

Post by PavoGa »

lotsaram wrote: Mon Feb 25, 2019 1:12 pm
PavoGa wrote: Mon Feb 25, 2019 12:39 pm I have found that a temporary subset is not available to a subsequent MDX query within the same TI. In that case, the first query has be a permanent subset and is removed in the Epilog.
You mean using one subset as the base set for another? As in either ...
{FILTER( [Dimension].[Temp Subset], filter condition )}
or
{FILTER( {TM1SubsetToSet( [Dimension], "Temp Subset" )}, filter condition )}

If yes we have noticed that too but I put it down to "expected behavior". Easy enough to work around by reusing the whole MDX of the first subset and embedding it in the 2nd as opposed to trying to use the subset.

If that's not what you mean then probably others don't know either not just me.
That was exactly what I meant, but I was a little surprised it did not work. I go ahead and add the first one as a regular subset and to shorten the code of the second subset and remove it in the Epilog.
Ty
Cleveland, TN
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Temp View difference to Perm Views

Post by lotsaram »

paulsimon wrote: Mon Feb 25, 2019 2:34 pm Hi Lotsaram

I am probably too stupid to realise that it couldn't be done and just went ahead and did it since it seemed like a logical thing to be able to do.

Anyway, I suggest you try an experiment yourself to confirm it.

Regards

Paul
Buried away (not in the release notes, mind you but buried in the reference material) the actually is a statement that the scope of temp objects changed as of v 11.3.0 from the immediate process to include sibling and ancestor processes that are part of the same ExecuteProcess chain.
However from some defects which I have raised I know that temp subsets don't work correctly on alternate hierarchies until 11.4. Therefore I would recommend 11.4 as the minimum version for PA for anyone moving from 10.2.2 to v11.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
dharav9
Posts: 72
Joined: Wed Aug 15, 2018 3:18 pm
OLAP Product: TM1
Version: 10.3
Excel Version: 2016

Re: Temp View difference to Perm Views

Post by dharav9 »

Steve Rowe wrote: Thu Feb 21, 2019 8:18 am As every the most right thing is to give the developer the tools to make the choice themselves of the scope of the object.
Flag values of
0 - Permanent object
1 - Temp and local to the creating TI only.
2 - Temp and global to the entire TI chain.
Hi, Steve

I just want to confirm for my understanding - If we want to assign the same view across all ExecuteProcess() resides in current TI, then we should put Flag 2 instead of 1?


https://www.ibm.com/support/pages/tm1-1 ... ry-objects

Thank You for sharing - I did not know about Flag 2. IBM tech note also did not include.

Dharav
lotsaram
MVP
Posts: 3651
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Temp View difference to Perm Views

Post by lotsaram »

There is no flag 2!
This was Steve’s suggestion at the time that temp objects existed only for the immediate process.
Temp objects are now available throughout the whole ExecuteProcess chain.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
Post Reply