fix: Sorting & Display of FSE

[dhaselhan]

• Sort both paginated and non paginated by create date asc to match other schedules
• Fix kWH usage column to use nice number formatter without decimals

[github-actions]

Frontend Test Results

  1 files  ±0  116 suites  ±0   39s ⏱️ -1s
390 tests ±0  367 ✅ ±0  20 💤 ±0  3 ❌ ±0 
392 runs  ±0  369 ✅ ±0  20 💤 ±0  3 ❌ ±0 

For more details on these failures, see this check.

Results for commit ac49b23. ± Comparison against base commit 5fa0ddc.

♻️ This comment has been updated with latest results.

[github-actions]

Backend Test Results

501 tests  ±0   501 ✅ ±0   1m 52s ⏱️ -1s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit ac49b23. ± Comparison against base commit 5fa0ddc.

♻️ This comment has been updated with latest results.

[hamed-valiollahi]

Looks good to me!

As a suggestion, would sorting by id be more efficient here since integer comparisons are typically faster than timestamp comparisons like created_date?

[dhaselhan]

Looks good to me!

As a suggestion, would sorting by id be more efficient here since integer comparisons are typically faster than timestamp comparisons like created_date?

Depending on how ETL works this may or may not be true. ETL may insert records with a higher ID but a copied Create Date from TFRS. Ill ask Alex.

[hamed-valiollahi]

Looks good to me!
As a suggestion, would sorting by id be more efficient here since integer comparisons are typically faster than timestamp comparisons like created_date?

Depending on how ETL works this may or may not be true. ETL may insert records with a higher ID but a copied Create Date from TFRS. Ill ask Alex.

Thank you! In case there is significant improvement, we can also update the ETL to ensure the correct order of fetching data. Also, I noticed that there are a few places in the database where the tables don’t have proper indexing. It would be great if we could check and address that as well.

[dhaselhan]

Looks good to me!
As a suggestion, would sorting by id be more efficient here since integer comparisons are typically faster than timestamp comparisons like created_date?

Depending on how ETL works this may or may not be true. ETL may insert records with a higher ID but a copied Create Date from TFRS. Ill ask Alex.

Thank you! In case there is significant improvement, we can also update the ETL to ensure the correct order of fetching data. Also, I noticed that there are a few places in the database where the tables don’t have proper indexing. It would be great if we could check and address that as well.

Talked to Alex, he mentioned we are transferring Create Date so we can use that.

[hamed-valiollahi]

Nice, thanks, Daniel!