feat!: add wait/handle time to ProcessedMessage

[kbond]

Fixes #97.

This is a BC break and will require existing apps to create a migration. The migration would need to either clear the existing ProcessedMessage's or calculate the values when adding the fields.

This isn't ideal but feels like the best way to eliminate the timestamp diff db logic that DB platforms all handle differently.

TODO:

• UPGRADE.md

[kbond]

💪🏻 Ok, averageWaitTime & averageHandlingTime work consistently across sqlite/mysql/postgres.

I think this is the best way to handle but @Chris53897, @SherinBloemendaal, @bobvandevijver, any thoughts?

[bobvandevijver]

LGTM 👍🏻

[bendavies]

@kbond how about storing micro seconds for sub second precision?
many of my messages show 0 seconds for handled time, it would be great to see milliseconds!!
maybe squeeze in before the 0.5 release?

[kbond]

I was thinking about this.

My only concern is timestamp fields don't store partial seconds (IIRC). Maybe not an issue but the timestamps and wait/handle time's won't match up.

Thinking to store as seconds * 1000 instead of a decimal field to avoid any inconsistencies between db platform (not sure if there are any).

Need to make this decision before 0.5.0 to avoid a BC break for existing data...

[bendavies]

here i used decimal(16,6) with DateTimeImmutable->format('U.u') and it seemed fine on postgres and mysql
SymfonyCasts/messenger-monitor-bundle#43

[kbond]

Ok cool, I have tests for different db platforms now so let's see!

[kbond]

Why did you use decimal instead of float for the type? From what I'm seeing, a float would require less bytes than a 16,6 decimal.

[bendavies]

floats didn't work on mariadb

SymfonyCasts/messenger-monitor-bundle#43 (comment)
SymfonyCasts/messenger-monitor-bundle#43 (comment)

SymfonyCasts/messenger-monitor-bundle@1fed242 (#43)

[kbond]

Ok, good to know! Decimal it is

[bendavies]

i'm actually not sure if my comment back then was a typo and i meant postgres.
but compare these on postgres and you'll see floats suffer from the same problem as php with floats.

SELECT avg(n) FROM unnest('{0.1,0.2}'::float[]) n; # 0.15000000000000002
SELECT avg(n) FROM unnest('{0.1,0.2}'::decimal[]) n; # 0.15000000000000000000

[kbond]

I watched this also: https://planetscale.com/learn/courses/mysql-for-developers/schema/decimals

Which talks about the same thing but... For milli or even micro seconds, this approximation would be fine, no?

[bendavies]

sure it'll use more bytes for storage, but is that a concern given the other columns on this table which are far larger?
that said, this does seem a valid occasion where an approximation might be seemed good enough.

[bobvandevijver]

Why not just store the milliseconds (or even micro) in the int field? I very much doubt that (assuming 64 bit signed, bigint in mariadb and postgres) wait time and handle time would ever by larger than 2.56*10^9 hours.

Unsigned ints are not supported on postgres, so that is not an option.

Personally I always try to stay away from floats whenever possible.

[kbond]

Ok, I was also thinking storing the milliseconds. I think I'll do that. I doubt there's a need for knowing down to the microsecond.