Need 3rd system table - Implemented

On this forum you can see a list of new features requested by users and you can also cast your own vote (you need to login to vote).
Post Reply
Posts: 1459
Joined: Wed Sep 30, 2015 10:08 pm
Location: Ocala FL

Need 3rd system table - Implemented

Post by BLOMASKY »

There is currently System Settings, one per application and Regular User, one per user. Both persistent. Can I suggest we have a new NON-persistent BO, perhaps called Session Variables. It would work like this;
• When user logs on, a unique GUID is created and the Aware server creates an in memory table with this GUID as the key.
• The application can update and read attributes defined for this BO. Initally, since non-persistent, all of the attributes would be UNDEFINED
• When the browser is reloaded, a new GUID is created and therefore a new BO is instantiated.

The advantage of this is that with proper coding, a user can have multiple browser instances open, since it is non persistent, there can be some performance gains, compared to storing variables in LIRU.

Anyone else have a need for this functionality?

Last edited by BLOMASKY on Sat May 22, 2021 2:44 am, edited 1 time in total.
Posts: 78
Joined: Mon Sep 07, 2020 6:03 am
Location: Netherlands

Re: Need 3rd system table

Post by nhofkes »

I think this is now implemented in version 8.5?
See item #2 here ... 630#p54630 and page 135 of the User Manual.

(V9.0 build 3241 - MariaDB - Windows)
Posts: 4238
Joined: Sat Mar 10, 2007 6:44 pm

Re: Need 3rd system table

Post by tford »

Thanks for bringing session values back to min, Niels.

From the Persistence section of the User Guide:

If you choose Not persisted option instances of the business object will be temporarily created in memory (see Data Storage). In this case the instances are destroyed when they are no longer needed by those rules that create and use them.

Here you can also check the “Store Session Values” checkbox to indicate that this object will be special – the instance of this object will be automatically created when a user logs in. There is only one instance of this object per user and the instance is always present in Context. Which means that you can use the object to store attribute values that are persisted in memory only for the duration of the user session.
Tom - V8.8 build 3137 - MySql / PostGres
Post Reply