Wim Gielis wrote:
Something strange I noticed (only) now.
When you use TI to create a view and you use ViewCreate and ViewSubsetAssign, the corresponding *.vue file will contain:
7,dimensionname
6,ALL
So the (implicit) subset is put as ALL, for every dimension even if you specify a valid subset in 1 or more cube dimensions.
The view looks good in Architect (the correct subsets are applied), and the Properties window in Architect also displays the correct subsets.
You have to go in the view and save it before TM1 updates the *.vue file.
Am I missing something, or would it be a bug of some sort ? TM1 10.2.2.6
I don't think it's a bug. The big thing to bear in mind is that TM1 does not always read from its files while it's running for obvious performance reasons. When Manny said "in memory", he
meant "in memory". That's why you can't update a TI by, for example, the simple method of slipping a new .pro file into the data directory while the server is running, even though many of us have probably wished that it were so over the years.
When you create the view, TM1 creates the .vue file but I think this is just a "marker". It does not, as far as I am aware, re-read from the .vue file again until reboot time. (We're talking
public views here, which of course TI views are; private views are read on user login, but that's not relevant here.) It doesn't
need to because the definition of the view is stored in the server's memory following its creation. (Hence the reason that you see the correct view in Architect.) That being the case, there is nothing to be gained by spending the time writing the view definition back to disk every time the definition is altered by, for instance, a ViewSubsetAssign command. It just becomes another disk write that has to be done. (In fact it didn't even
have to write the .vue file in the first place; not at that time anyway. There are probably data integrity reasons for it to do so; maybe as a reminder at shutdown that this definition is there, maybe to allow it to do a cross-check of in memory definitions against the .vue files and report inconsistencies, maybe as insurance against a server crash; I don't know. But the key point is that it need not do it.) Incidentally, a ViewDestroy will delete the file as well.
Which brings me to the key point; you won't
only see the .vue file update if you open the view and save it, but
also if you do a data save on the server. The purpose of that save is of course to tuck everything that is in memory away to disk. And this apparently includes not just data, but also view and other definitions that may have been created during the preceding session.
It's different when you use the GUI; there you define the entire view and when you hit [Save] only a single write operation is done. With TI you have the potential of having to do up to a write per dimension (if a subset is assigned for each one), plus one for each export flag or dimension set, etc. It probably matters less with modern hard disk systems (especially SSDs) but it may have once mattered a lot.
I'd therefore rate this one as "expected behaviour"; it's only the (
seeming) inconsistency of creating the .vue file when ViewCreate is called that makes it appear to be anything else.
