Custom RetentionPeriod

[TayfunCesur]

⚠️ 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.

💡 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.

🙋 Do you want to develop this feature yourself?

• 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 or CustomType(periodInMills : Long)
• Other ideas?

[cortinico]

Thanks for opening this issue.

• Cutting out the enum and walk with Long or CustomType(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.

[TayfunCesur]

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 👋

[cortinico]

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.

[TayfunCesur]

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.