Reducing SystemSettings and RegularUser Bloat

UnionSystems

A frequent AwareIM additional feature request is additional always in context objects to reduce dependence on SystemSettings and LoggedInRegularUser. I understand the common problem just using SystemSettings and LoggedInRegularUser is they get way too large (too many attributes).

I am guilty of having an enormous SystemSettings that has hit the mySQL row size limit. Not only is this ugly it adds a performance burden on AwareIM as it always loads this enormous row. I’ve found a ”work around” that seems to solve my problem and I’m keen to get critique from the learned AwareIM community.

As an example of the “work around” I have a set of 12 SystemSettings attributes that contain the current last 12 month as text “2019/April” through “2020/March”. These are used as column headings of a Query whose columns slide one month every month (so the query only shows the last 12 months columns). Anyway storing these in SystemSettings as ColHead_1 , ColHead_2 etc they render in the Query by using the token syntax of <<SystemSettings.ColHead_1>> <<SystemSettings.ColHead_2>> but this of course adds yet another 12 attributes to my already bloated SystemSettings.

So what I had done instead is create a separate object QueryCol with attributes Head_1, Head_2 etc and a single reference attribute from SystemSettings to the QueryCol object called ps_QueryCol. This reference has to be set once (I do it from my VP login processes). Then I change <<SystemSettings.ColHead_1>> <<SystemSettings.ColHead_2>> to <<SystemSettings.ps_QueryCol.Head_1>> <<SystemSettings.ps_QueryCol.Head_2>>. This seems to work fine. So I’m thinking rather than shoving everything into SystemSettings it would be better to create different objects and reference them from SystemSettings. Apart from reducing the bloat of SystemSettings I like the tidiness of having more smaller objects housing distinct sets of attributes.

I assume the same thing could be done to extend LoggedInRegularUser.

Am I missing something?..

Jaymer

1) are there any Shortcuts in SS to these ref tables?
Shortcuts add an EXTRA SQL query in the logger to resolve the shortcut value.

2) If you ever referenced any of these "linked" fields in a HTML statement, then that causes an extra hit to the DB. Vlad has said "HTML cells are resolved on the client, not on the server." so I think each time you'd put one of these fields in some HTML cell that would cause an extra explicit hit to the db

3) I've thought about this too, but I see the logger making an extra db hit for each reference table in my RegUser table. Adding another linked table makes Aware have to go get it in an extra hit. I'm not sure that in a 1-to-1 situation that its not better/worse than just having those fields "bloat" the RegUser table to begin with.

... but I may be wrong. Would love for someone to spend some debug/logger time to disprove me.

PointsWell

UnionSystems wrote
A frequent AwareIM additional feature request is additional always in context objects to reduce dependence on SystemSettings and LoggedInRegularUser. I understand the common problem just using SystemSettings and LoggedInRegularUser is they get way too large (too many attributes).
...
I assume the same thing could be done to extend LoggedInRegularUser.

Am I missing something?..

If you turn on SQL logging you will see that you aren't getting a performance enhancement (though you are fixing your row limit and potentially tidying up you grouping of settings)

I have veered away from putting BOs into LIRU and SysSettings and instead just put the ID into a field.

Upside: lighter LIRU
Downside: only the ID is in context so you have to go find the object.

What you gain in performance you lose in having to bring it into context all the time.

The LIRU loads ALL the referenced BOs all the time and down the full chain of child BOs, to the point that it is really hard to debug the SQL that you want.

It would be nice to be able to embed a BO into a VP so that you have the BO there whenever the BO becomes active and while you are processing it but not otherwise (I appreciate this is probably very specific to my design method)

aware_support

In the next version there will be a special "session" object that you can define. This object will be persisted in memory, will always be available in Context (just like SystemSettings and LISU) and you can define attributes of such object as you see fit. The object will be automatically created when the user logs in and deleted when he logs out.