Below are the different types of states that can exist within an application. There are three main types:

1. Local State

Local state pertains to a single component. An example of this would be listening to user input in a field or toggling a “show more details” button. Typically, local state is managed within the component using useState or useReducer.

2. Cross-Component State

Cross-component state impacts multiple components. For instance, managing the open/closed state of a modal overlay. While this can also be managed using useState or useReducer, it often involves passing state between components via props drilling.

3. App-Wide State

App-wide state influences the entire application, such as themes or user authentication status. Similar to cross-component state, this can be managed using useState or useReducer, albeit with the assistance of props drilling.

The LISTAGG analytic function, introduced in Oracle 11g Release 2, greatly simplifies string aggregations within SQL queries.

SELECT pid, LISTAGG(ColumnName, ' ' ) WITHIN GROUP (ORDER BY seq) AS ColumnName
FROM B GROUP BY pid;

However, if the output of the above query exceeds 4000 characters, it triggers an error, specifically ORA-01489, indicating that the result of string concatenation is too long.

To address this limitation, Oracle Database Release 2 (12.2) enhanced LISTAGG with the ability to handle overflow errors gracefully, as demonstrated below:

SELECT pid, LISTAGG(ColumnName, ' ' ON OVERFLOW TRUNCATE ) WITHIN GROUP (ORDER BY seq) AS ColumnName
FROM B GROUP BY pid;

In this updated syntax, the output is restricted to 4000 characters, preventing the ORA-01489 error from being raised.

The ON OVERFLOW clause offers several options to manage overflow situations:

• ON OVERFLOW ERROR: This is the default behavior, triggering an error if the result overflows.
• ON OVERFLOW TRUNCATE 'StringYouLike': Appends ‘StringYouLike(Count)’ at the end of the truncated string.
• ON OVERFLOW TRUNCATE '': Displays the first 4000 characters without any additional terminating string.
• ON OVERFLOW TRUNCATE WITH COUNT: Appends the total character count at the end, for example, ‘…(5512)’.

References

Stack Overflow.

Session and token authentication methods are used by the server to verify the client request is authenticated or not.

Session Authentication

Session-based authentication is an example of stateful authentication, which involves storing user authentication data on the server. With this method, when a user logs into a website, the server creates a small file that stores user information such as a unique session ID, login time, expiration time, and other relevant data. This file is stored in the database or in-memory cache. This session ID is then sent back to the client and stored in the client’s browser as a cookie. For subsequent requests, this cookie is passed back to the server. This allows the server to verify the session ID and provide a response based on the current state.

This method is easy to use, as cookies are natively supported by browsers, so no additional JavaScript is needed. But when the application grows decoupling the frontend from the backend becomes essential. Session-based authentication can be limiting in this regard.

Token Authentication

Instead of relying on server-side sessions, token-based authentication uses tokens and it is an example of stateless authentication. When user log in, the server create a token (usually a JSON Web Token, or JWT) using a secret key and sent to the user. For subsequent requests, user will send this token along with request and server will verify if the token is valid or not.

This method gives more scalability and stateless for the apps, but the server does not authenticate the user, so linking a token to its user can be more difficult. Also in any chance an attacker got acess to the token, they will get access to the server.

References

LogRocket, Authfear, criipto.