« first day (2746 days earlier)      last day (2206 days later) » 

2:23 AM
ooh problem exists between chair and keyboard
 
 
16 hours later…
6:12 PM
What's the best way to reset each particular user meta every month? (cron jobs?)
 
6:32 PM
If timing is super important then server cronjobs will be your best bet.
 
6:44 PM
@bravokeyl that doesn't sound particularly scalable, can you provide some context? I suspect there's a superior tradeoff that trades storage space for speed
 
7:04 PM
Timing is not super important.
The context here is ad listing by registered users where every user can bump 3 ads per month and this counter should be reset to 3 every month 1st day
 
If timing isn't important you could get away with a wp cron.
 
Okay, so looping through all registered users and updating user meta with wp cron is good enough right?'
 
7:50 PM
I don't see why you would need to loop through all registered users and not just whatever the current user is, or whatever the current ad is.
Looping through all registered users and updating their metadata to clear out a value sounds labor intensive. Maybe update/clear what you need via SQL. If you can find a way around updating a ton of users all at once that's probably your best route.
 
8:06 PM
Ok
 
8:17 PM
looping through them all would place upper limits on the number of users you could process
instead, consider putting the year and month in the meta key
this way when the next month comes along, you instantly ignore all existing data with a new counter
now the problem is one of cleanup
 
@bravokeyl the user meta table is terrible for search queries. I'd use a separate table with user_id | ad_count and TRUNCATE is once per month.
 
> instead, consider putting the year and month in the meta key

This seems a good option.
 
see Fuxias comment though, the cleanup would probably involve pulling in a set of users in batches of 30-50 and manually inspecting their meta in PHP to avoid searching
 
@fuxia okay.
 
another option is to store each unlock/event with the same key, bundling in a time, then grabbing them when you check and checking each to see how many fall within a time period
that would mean no cron jobs, at the cost of extra rows
if strictness isn't a priority you could eliminate all the server side stuff by doing it client side
 
8:26 PM
ok, thanks for all the options, everyone.
 

« first day (2746 days earlier)      last day (2206 days later) »