Re: [Dev] [Identity Server] Storing the calculated expiry timestamp along with the OAuth tokens

Fixing typo :-) 1) A query with the DATE_ADD function d hit doesn't the index of TIME_CREATED. ==> 1) A query with the DATE_ADD function doesn't hit the index of TIME_CREATED and does a full table scan. On Mon, May 21, 2018 at 8:43 PM Rushmin Fernando wrote: > Sorry if I

Re: [Dev] [Identity Server] Storing the calculated expiry timestamp along with the OAuth tokens

Sorry if I didn't explain it correctly. It is not the calculation itself. Because the calculation based on fields of the table the DB is not able to use the indexes for the search. Please see a simplified test below. 1) A query with the DATE_ADD function d hit doesn't the index of TIME_CREATED.

Re: [Dev] [Identity Server] Storing the calculated expiry timestamp along with the OAuth tokens

On Mon, May 21, 2018 at 8:10 PM, Tharindu Edirisinghe wrote: > Currently in the IDN_OAUTH2_ACCESS_TOKEN table, we store the time of token > generation in TIME_CREATED column in human readable date time format. > Therefore at the time of token generation, we'll have to get the

Re: [Dev] [Identity Server] Storing the calculated expiry timestamp along with the OAuth tokens

Currently in the IDN_OAUTH2_ACCESS_TOKEN table, we store the time of token generation in TIME_CREATED column in human readable date time format. Therefore at the time of token generation, we'll have to get the current timestamp and store it in another column and also add the VALIDITY_PERIOD to

[Dev] [Identity Server] Storing the calculated expiry timestamp along with the OAuth tokens

Hi Devs, Right now it is the validity period which is getting stored along with the tokens. So in order to expire a token, a calculation is needed during expiry tasks. When there a lot of tokens, this becomes a bottleneck since the database indexes are not applicable. But if the expiry