Prune stored history to max_items per user

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.

[MACscr]

Problem

Recently::add() writes one row per (user, distinct URL) and never removes any. max_items only caps what the menu and global search display, so recent_entries grows unbounded — an active user accumulates a row for every distinct record they've ever viewed.

Change

After recording an entry, prune the user's rows down to the most-recent max_items (the config value). Ties on updated_at are broken by id so the newest insert wins when timestamps collide. Pruning is scoped per user, so other users' history is untouched.

Notes

• No public API change — add()'s signature is unchanged.
• Independent of any other change; based on 3.x.
• Tests added (tests/src/RetentionTest.php): stored count stays at max_items, the oldest entry is dropped and the newest kept, and a second user's history is untouched. composer test is green.
• README updated with a "Retention" section.

[awcodes]

Can you target this to the 2.x branch?

I think it should have Filament v4 support as well.

I'll merge it to 3.x once everything is green.

[awcodes]

Thanks for this — the table growing unbounded is a real problem and the prune query itself is the right shape. The two-step pluck/delete sidesteps the MySQL DELETE ... WHERE id IN (subquery with LIMIT) restriction, and the id tiebreak is a good call. Merges cleanly on 3.x and the suite is green.

One blocking issue and a couple of things to consider.

max_items is read from the wrong place

prune() uses config('recently.max_items'), but the menu reads RecentlyPlugin::getMaxItems(), which lets a panel override the config:

publicfunctiongetMaxItems(): int
{
return$this->evaluate($this->maxItems) ?? config('recently.max_items');
}

So anyone using RecentlyPlugin::make()->maxItems(50) with the default config of 20 now permanently loses entries 21–50. Confirmed with a throwaway test against this branch:

Filament::getCurrentOrDefaultPanel()->plugins([RecentlyPlugin::make()->maxItems(50)]);
for ($i = 0; $i < 30; $i++) {
Recently::add("https://example.test/page/{$i}", '', "Page {$i}");
}
expect(livewire(RecentlyMenu::class)->instance()->records)->toHaveCount(30);

Failed asserting that actual size 20 matches expected size 30.

The user asked for a 50-item menu, viewed 30 records, and sees 20 — with the other 10 deleted, not just hidden. Multi-panel setups are worse: the lowest configured limit anywhere wins, destructively, for every panel.

Worth adding a test that covers a panel-level maxItems() larger than the config value, since that's the case that regresses.

Default-on data deletion

max_items is currently documented as a display cap, so deleting rows on upgrade is a behavior change for anyone who set it low and later intended to raise it, or who queries recent_entries directly. Would you consider making retention opt-in — a separate 'max_stored' (or 'prune' => false) config key — so the destructive part is a choice rather than something that happens on composer update? That would also sidestep the display-vs-storage coupling above.

Minor

add() now issues two extra queries on every non-Livewire page render. Cheap, but you could skip the delete entirely when the stored count is already at or under the limit.

If #39 also lands

The two changes interact: this PR prunes to max_items counting entries whose record has since been deleted, while #39 hides those from the menu. A user who deletes a lot of records ends up with a near-empty menu while N rows sit in the table. Dropping non-existing entries first inside prune() would resolve it.