Added a custom index for LogEntry__c.OriginLocation__c

[jongpie]

Fixes #400 by adding a custom index for the field LogEntry__c.OriginLocation__c, using the new CustomIndex metadatatype. This should help to improve queries & reports that filter on this field.

[jongpie]

I've been doing some testing of the new CustomIndex metadata type - overall, it seems to work well, but I'm currently running into issues with trying to delete a custom index.

I've tried deleting with sfdx using both the new source and older mdapi commands, but neither seems to work - they both throw an exception insufficient access rights on cross-reference id

• sfdx force:mdapi:deploy -d ./customindexDelete -w -1 (assuming you have a folder called 'customindexDelete' with all of the appropriate XML files)

  

• sfdx force:source:delete --metadata CustomIndex:LogEntry__c.OriginLocation__c

  

I'll continue testing this - it makes me a little nervous to merge this PR before having a rollback plan in place (just in case there's some negative impact in some orgs), so I want to figure out deleting the index before I release this change.

[JeroenSfdc]

Agree @jongpie since not documented as such, that fact that deploying the meta-data 'works' (did you run an explain plan to see if truly the field was indexed, not only 'checked' as indexed) is tricky. Risk-reward is not such that this needs to be pushed.

[jongpie]

@JeroenSfdc yeah, I ran a few tests before & after deploying the custom index, and it does appear to be actually indexing the field - but given that I haven't found a way yet to delete the custom index, I'm going to hold off on merging this PR for now.

I'll try reaching out internally at Salesforce to see if anyone can provide me with some more info on the new metadata type - if/when I can figure out how to delete a custom index, then I think I'll move forward with merging this PR.

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (da3bbaa) 95.07% compared to head (9cdba05) 95.07%.

❗ Current head 9cdba05 differs from pull request most recent head 99b3da8. Consider uploading reports for the commit 99b3da8 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #411   +/-   ##
=======================================
  Coverage   95.07%   95.07%           
=======================================
  Files          59       59           
  Lines        5944     5944           
  Branches      129      129           
=======================================
  Hits         5651     5651           
  Misses        288      288           
  Partials        5        5           

Flag	Coverage Δ
Apex	95.49% <ø> (ø)
LWC	92.83% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...-logger/core/main/logger-engine/classes/Logger.cls	96.11% <ø> (ø)
...ogger/core/main/logger-engine/lwc/logger/logger.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jongpie]

@JeroenSfdc this is now available in the v4.10.5 release. I've talked with a few other people that are using the new CustomIndex metadata type, and so far, it seems to be going well for everyone, so it made sense to finally merge this PR.

[JeroenSfdc]

Nice @jongpie! Since we're on the manage package, will need to wait a bit. Thanks a lot!

[jongpie]

@JeroenSfdc just FYI, I'm hoping to have the managed package release (v4.11.0) released next week (PR #507) 🥳 It'll include the new custom index, as well as a few other enhancements).

[jongpie]

@JeroenSfdc, some unfortunate news, I'm not going to include the custom index in the next managed package release (v4.11.0)

I've recently seen a few errors about the custom index in a couple of unrelated orgs that deploy Nebula Logger's metadata (instead of using the unlocked or managed packages). For some reason, the inclusion of the custom index causes a deployment error. It doesn't seem to be a widespread issue (I only know of 2-3 orgs impacted)), and I can't reproduce the issue myself in any of my own orgs, so it could be something specific to those orgs. But as a precaution, I'm going to exclude it from the managed package this release to avoid any upgrade issues.

In the meantime, I'll continue to investigate these errors further - hopefully, I'll be able to include the index in the next managed package release, v4.12.0 (Winter '24).