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.

In software development, a canary release (or canary deployment) refers to the practice of rolling out a new version of software to a small, select group of users before deploying it to the entire user base. The term “canary” comes from the old practice of using canaries in coal mines to detect dangerous gases; if the canary showed signs of distress, miners knew to evacuate. Similarly, in software, the canary release acts as an early warning system to detect issues with new code before it reaches a wider audience.

Benefits of Canary Releases: Reduced Risk: Limits the impact of potential issues by exposing the new version to only a small group first. Real-World Testing: Provides the opportunity to observe how the new version performs in a live environment. Faster Rollback: Easier to revert changes if problems are detected, reducing downtime or negative user impact.