I am wondering if anyone has an informed opinion on when to use Namespace datasources as opposed to using attributes within Session.storage.
Currently, I really dig the versatility of Namespace datasources. Easy to assign through user interaction, easy to access, and from what I understand they are clientside, so every user has her own set of Namespace datasources within their session.
I understand that due to semaphore-like usage of Session.storage attributes through “Use”, there must be situations when concurrency becomes an issue. What am I missing?
persistence.
think of it as a substitute for storing parameters in a system parameters dataclass. granted, the dataclass will persist even longer than Storage, as when the instance of the server restarts, the Storage will be reset.
Is that true? If I hit “refresh” in my browser, both the Namespace datasources and the session attributes are reset. I see no difference in persistence there. The datasources I think of are basically interprocess variables in 4D terms. The difference I see between Namespace and Session is that Session offers concurrency support but then again I don’t see concurrency issues here.
Qodly Studio namespaces are primarily intended to allow you to share datasources between webforms.
They are client-side and each user has his own set, you’re right.
Session.storage is a server-side shared object.
You can use it to store server-side info, that are specific to a given session.
The use of “use … end” is required because session.storage is a shared object.
It allows you to perform preemptive processes on session.storage attributes.
Both concepts are similar but their usage is different. I would use session.storage to store attributes that are not necessarily displayed or even used by a webform. Data that I want to keep server-side, to keep them safer.
And you could also imagine running preemptive process accessing/writing session.storage attributes.