Q - Alternative to LoggedInRegularUser

PointsWell

I'm mulling over the LoggedInRegular user issue and how creating too many references to objects in it can slow the server down. I also have noticed that it triggers any rules that are on the Regular User object.

I was wondering if an alternative would be to create a reference BO to the RegularUser and store all the objects in that as that would reduce the size of the table. For example

LoggedInRegularUser.om_Variables.ps_ReferredBO

Is this a viable solution and might it lessen the load on the server?

ACDC

In your Object rules, there is an option "Do Not Check Referred Objects" check this on all your objects rules in your BSV
Only "uncheck" if you really, really, really, have to - this will speed things up big time in complex apps

PointsWell

ACDC wrote
In your Object rules, there is an option "Do Not Check Referred Objects" check this on all your objects rules.
Only "uncheck" if you really, really, really, have to - this will speed things up big time in complex apps

Thanks I'll bear that in mind.

I'm still interested in the impacts +/- on the idea of variables being held on a related table rather than the LIRU BO.

BLOMASKY

why do you care if there are 10 or 1000 fields in your LoggedInRegularUser (LIRU)? One of the pluses of using LIRU is that it is ALWAYS in context. If you create a diff. object, you will always have to do a FIND MYObj where user = xxxx for every process that has to read / update it.

bruce

UnionSystems

I notice when you expose an object in context via an Aware IM REST service it shows all related objects and their attributes (which can be rather huge). I suspect (but I'm only guessing) this could mean that offloading attributes from LoggedInRegularUser to a related BO would NOT speed processing up and perhaps make it slower as the relationships would have to be loaded.

An alternative might be to create a "shadow" (my term) BO that does not have a relationship but that has a common "LoginName" attribute and move some of your extra attributes into this "shadow" BO. Could even use multiple alternative BOs and use them to store different types of attributes (ie attributes pertaining to different areas of information). I understand document attributes in the LoggedInRegularUser is a particular burden. I'd think these might be good attributes for moving into a "shadow" BO.

When you need to access those shadow BO attributes you would have to load that shadow BO instance into context. For example if your shadow BO was called "RegUserShadow" you would load it into context with :

FIND RegUserShadow WHERE LoggedInRegularUser.LoginName = RegUserShadow.LoginName

Again all of the above is an untested guess.

PointsWell

BLOMASKY wrote
why do you care if there are 10 or 1000 fields in your LoggedInRegularUser (LIRU)? One of the pluses of using LIRU is that it is ALWAYS in context. If you create a diff. object, you will always have to do a FIND MYObj where user = xxxx for every process that has to read / update it.

bruce

At the moment I am not concerned, but this post
https://forum.awareim.com/d/9391/1&hilit=Slow+loggedInRegularUser#p42244

has made me mindful of the potential to ever use LoggedInRegularUser (LIRU) especially as some of the BOs that I have are quite large and can be sparse (I have modelled the data for two years and this is the most efficient it will get for a variety of reasons)

Which is why is wondered if a related table to the LiRU would make a difference - being connected to LIRU would mean that you could traverse the LIRU but still keep the LIRU quite light or whether this still impacts the LIRU as described in the post above.

PointsWell

UnionSystems wrote
I notice when you expose an object in context via an Aware IM REST service it shows all related objects and their attributes (which can be rather huge). I suspect (but I'm only guessing) this could mean that offloading attributes from LoggedInRegularUser to a related BO would NOT speed processing up and perhaps make it slower as the relationships would have to be loaded.

This was my concern with my suggestion.