chucker
chucker copied to clipboard
Custom RetentionPeriod
:warning: Is your feature request related to a problem? Please describe
It is not a blocker problem but I think it is an improvable point. I am using chucker in my personal project and I saw that
- Every time when I launch the app, I see the old transaction history (which is definitely trash for me) and it is really hard to find where/when the new requests started.
- The only way to see the new transactions per session is removing all history manually every time.
:bulb: Describe the solution you'd like
In ChuckerCollector
, we have retentionPeriod
as RetentionManager.Period
. I think ,enum usage restricts us. I'd prefer to have a Long
or some custom type that accepts Long like CustomType(periodInMills : Long)
We could extend the current Enum but it wouldn't fit for all cases. For example someone would need 15 min period in someday? Either way, that retentionPeriod
value is being converted to mills.
Thanks.
:raising_hand: Do you want to develop this feature yourself?
- [x] Yes I can also participate the development after the final decision has been made.
- Extending the enum
- Cutting out the enum and walk with
Long
orCustomType(periodInMills : Long)
- Other ideas?
Thanks for opening this issue.
- Cutting out the enum and walk with
Long
orCustomType(periodInMills : Long)
I've reasoned a bit about this feature request and I'd love to raise a point.
How long would you set the periodInMills
for your use case? Setting it to say 1000
(1 second) will wipe all the transactions that are older than 1 second.
My understanding is that you'll like instead to wipe the transactions list every time you open Chucker. If so, we should add a boolean flag as @vbuberen was suggesting on Slack (https://kotlinlang.slack.com/archives/CRWD6370R/p1607809445019800) and code this behavior separately from the Period
enum.
Hi @cortinico , yes having a boolean in ChuckerCollector builder works for me. Actually I was thinking more generic and trying to cover all scenarios. Because after some time, every parameter would become a burden to maintain.
I asked myself, what if someone need 15 min period or 30 min period? Then I thought,
-
Cutting out the enum and walk with Long or CustomType(periodInMills : Long)
But of course, I am okay with boolean.
Thanks 👋
Actually I was thinking more generic and trying to cover all scenarios.
What I was saying is that having periodInMills : Long
would NOT cover your initial use case. If you wish to wipe the DB every time Chucker opens, there is no reasonable periodInMills
that will allow you to achieve that.
So I'd say we tackle your initial problem (wiping after every startup) and we defer the extension of the Period
enum if we have users requesting it.
Hmmm, now I got your point. I just checked the
private fun isCleanupDue(now: Long) = now - getLastCleanup(now) > cleanupFrequency
.
I was thinking to go with 0
cleanupFrequency, but then isCleanupDue
would be always true and I would see no record all time.
Thanks for pointing this out.