technical: add index for foreign keys

[hannesa2]

close #4971

[joragua]

Hi @hannesa2! Thanks for your contribution! 🙌🏻 Just a comment before the CR:

The calens entry is necessary for this fix, so could you add a new commit (chore: add calens file) including all the changelog information? Please don't forget to read the TEMPLATE.md before adding it. Let us know if you have any doubts and we will help you!

[hannesa2]

It's fine for me, when you maintain this calens stuff.
Btw, you could have this changelog much easier https://github.com/AppDevNext/AndroidChart/blob/9d7d728f6ef501168736184846889c6ad05a14c3/.github/workflows/Android-CI-release.yml#L59

generate_release_notes: true

[joragua]

Thanks for the suggestion! We will take a look at the yaml file that you mentioned 🤔

NOTE: Calens ≠ Release Notes. Calens is used for the changelog, while release notes are intended for end users

[hannesa2]

With https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes (which is the stuff under the hood) you can make categories of pull request, e.g customer-related, then it generates it by categories, and after this, you can easy delete stuff from output.
But why filter content ? This is the main issue for me. Be transparent !

[jesmrec]

It's not a matter of filtering.

Calens is intended to build the CHANGELOG, a complete list of features/fixes... included in an specific release. With no filter.

Release notes are a non-techie-readable list of main features that are interesting for the final users, whatever the profile of the user. They must be understood for everyone with no technical language.

For example, the current PR is not interesting for many final users, who don't care about DB indexes (unless they are techie users, in that case they can check the complete changelog), because they can't see that in the screen.

Anyway, thanks a lot for the suggestion, we'll take a look in case it's useful for us to integrate. For the moment, the calens file creation has to be done manually.

[hannesa2]

I see your point, but maybe it's not the most efficient way.
I've a super less afford release process in my mind, by only set a git tag

• No calens changelog
• No release notes
• No code touch

This all ends in a release commit outside the repo 🙈

Where you save your time for customer features and not for bureaucracy.

As I'm not a big fan of your inefficient way, that's why I at least tried in older days to improve it #2741 but with less success.

[hannesa2]

But to see it positive, you know better then me, what you really need and every afford comes with a price.
I can make only suggestions

[joragua]

@hannesa2 CR done! 🙌🏻 Just three comments:

1. Every commit must be GPG/PGP signed and include a Signed-off-by line. Use the command: git commit -s -S -m "..."for that. Unfortunately, we won't be able to merge the PR until all commits are properly signed.

2. Could yo add the calens file? Since we are not able to push changes to your branch because permissions

3. Check the suggestion below

Let us know if you have any doubts and we will help you! Thanks in advance!

[hannesa2]

@hannesa2 CR done! 🙌🏻 Just three comments:

1. Every commit must be GPG/PGP signed and include a Signed-off-by line. Use the command: `git commit -s -S -m "..."`for that. Unfortunately, we won't be able to merge the PR until all commits are properly signed.

Done

2. Could yo add the calens file? Since we are not able to push changes to your branch because permissions

I've no clue what to do here. Can you do it after the merge ?
I see this as bureaucracy (no feature, no bugfix), you introduced it, I suggest you handle it.
In the past I was able to push to your repository, but someone revoked my permission. Now we have an issue

3. Check the suggestion below

applied

[joragua]

Thanks for the changes @hannesa2! Two more comments about the PR:

1. CI is red because of the name of the third commit. Every commit must follow the conventional commits guidelines. Otherwise, the PR cannot be merged. Just amend the commit message and it's ready to go 😄

2. I noticed that the commits are showing as Unverified. Please check that the GPG key you're signing with locally is added to your GitHub account and that the commit email matches a verified email on GitHub.

Let us know if you have any doubts about the two points I mentioned 🙌🏻

[hannesa2]

It's not easy to help you.