feat: add additional wakatime fields

[ronchengang]

Wakapi is a very useful tool, I have been using it to record my work time. Recently I found that Wakatime has some very useful fields that are very helpful for code analysis, but these fields are not recorded in Wakapi. This change is to add these fields in.

These fields are

"dependencies": <string: comma separated list of dependencies detected from entity file (optional)>,
"lines": <integer: total number of lines in the entity (when entity type is file)>,
"line_additions": <integer: number of lines added since last heartbeat in the current file (optional)>,
"line_deletions": <integer: number of lines removed since last heartbeat in the current file (optional)>,
"lineno": <integer: current line row number of cursor with the first line starting at 1 (optional)>,
"cursorpos": <integer: current cursor column position starting from 1 (optional)>,

for all wakatime fields, please refer to https://wakatime.com/developers#heartbeats

[muety]

Thanks, but what's the point of including these fields without actually populating them with values?

[ronchengang]

Thanks, but what's the point of including these fields without actually populating them with values?

There are values ​​populating them. wakatime-cli is already collecting values ​​for these fields and included in heartbeats sending to server. I have implemented this change on my localhost and these values ​​are being populated. These are useful for code volume analysis.
It looks like this (not fake data, but real data from my database):

BTW, adding dependencies may cause json formatting error if the text is too long, I have removed it.

[muety]

You're right, sorry for not having thought about this a little more. May I ask how you're using these fields, since they're gonna be included in any summary and will not be shown anywhere on the UI?

Also two more remarks regarding your changes:

1. I'm generally not a big fan of using pointers to primitive fields just for the sake of nullability. Although others might have a different opinion on this, I'd even argue it's sort of an anti-pattern to do in Go. Because, this, way, you'll eventually end up cluttering your code with null-checks all over the place (like in Java or similar languages). If possible, I'd prefer to use zero-values (simply int in this case) instead - also for consistency with existing code.
2. Since this change will trigger a bunch of (very expensive) alter table queries as part of the auto-migrations during startups, we should place a note in the next release notes to warn people that their Wakapi instance might take a while to boot up after the upgrade. On my dev instance (which is a fraction of the size of Wakapi.dev), only the first query is currently still running for more than 20 minutes now (MySQL)...

[muety]

Will add a hint to the release notes to manually run the following commands before the upgrade (apparently, they don't require locking the table, so can be done at runtime):

# MySQL
alter table heartbeats
    add `lines`              bigint,
    add `line_no`            bigint,
    add `cursor_pos`         bigint,
    add `line_deletions`     bigint,
    add `line_additions`     bigint,
    add `project_root_count` bigint,
    algorithm = inplace;

# Postgres
alter table heartbeats
    add "lines"              bigint,
    add "line_no"            bigint,
    add "cursor_pos"         bigint,
    add "line_deletions"     bigint,
    add "line_additions"     bigint,
    add "project_root_count" bigint;

# SQLite
alter table heartbeats add column lines integer;
alter table heartbeats add column line_no integer;
alter table heartbeats add column cursor_pos integer;
alter table heartbeats add column line_deletions integer;
alter table heartbeats add column line_additions integer;
alter table heartbeats add column project_root_count integer;

[ronchengang]

@muety Thanks for pointing out the database migration part, I didn't realize it would take so long in a large dataset. I didn't see this problem because my dataset is not as large as yours, and there are only 3k heartbeats in the table.
I use these fields to track line changes of a single file before committing to a Git repo, which is a management requirement.
As for *, I understand your point about coding style and pattern. Actually, I also used Int (without *) in the first version of my change, but I soon found a problem: it always inserts a 0 value in the heartbeat table for some records sent by Wakatime Desktop, and these records should not have the concept of 'lines', like Outlook or Chrome, only editors such as VS Code, Cursor should have it. So for some cases, "null" value in the database makes sense. This is the main reason I use *int instead of int, it is not a purely technical consideration but also a practical thought.

[ronchengang]

In addition, I found something strange. I found a person named 'amaler' in the list of participants of this pull request. This person always appears in the list of participants, not only in this project, but also in other projects I have contributed to. It's really strange. do you happen to know where this person comes from and how he appears in the list of participants? Is this a hacker behavior, or is there something wrong with the configuration in my GitHub?

[ouuan]

In addition, I found something strange. I found a person named 'amaler' in the list of participants of this pull request. This person always appears in the list of participants, not only in this project, but also in other projects I have contributed to. It's really strange. do you happen to know where this person comes from and how he appears in the list of participants? Is this a hacker behavior, or is there something wrong with the configuration in my GitHub?

Your commits are all attributed to that user, because your local Git config uses git@git.com as your email. I'm not sure how that user managed to own this email account, though. You need to set git config --global user.email <your email address>.

[ronchengang]

@ouuan Hahahaha (laughing at myself), I knew it, again, I made such a stupid mistake... Thank you for telling me this.