Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hello,
I have to add a new functionality to a Laravel app : my client needs certain fields to be set automatically to null after some date only for some models.
For example in the clients table, he needs that only the birthdate and the SSN has to be set to null after 2022-10-31 only for John Doe.
Sure there will be some other clients for which it will be necessary.
How would be the better way to do that ?
I thought about this :
1 - add a json column in the table with the name of the fields to set to null and add another column with the date the datas have to be set to null
2 - add as many boolean fields as needed to specify the fields to set to null
Then a cron job to call the required method in a controller to run the query.
I think way 1 is best.
Perhaps you have another idea ?
Thanks.
Vincent
A different idea. Make a copy of the table structure, with a foreign key to the other table and a "activate_at" column. Set how each column should look at the given date. Then have a cron job check that table daily for what should be transfered.
You could set a random value for each column field that shouldn't be transfered
@Sinnbeck ok thank you. This means that I should copy the exact value I want for a line of a model at a date in another table. So each time I update the initial table, I also have to update the related table. How can I remember which field has to be set to null ?
For example I update the SSN, I need the new value, but next month or has to be set to null. At the same time I update the name, but the name has not to be set to null. So how can the app know which field it has to be copied to the second table ?
@vincent15000 what I meant was to have a simple indicator
| name | ssn | foobar |
| x | null | x |
Or true/false
| name | ssn | foobar |
| false | true | false |
Mostly to not clutter the original table
@Sinnbeck This idea is very interesting but the inconvenient is the necessity to create another table, and this is also an advantage because it's not necessary to add any field in the initial table. And if I need to add a new field in the initial table, I have to add it in the related table too.
And the json column has also inconvenient and advantage.
And probably this table will be quite empty, as the json column.
Is it better to have several empty fields or an empty table ?
@vincent15000 I would prefer a secondary table. Even if you go with the json version. You could even make it a morph table to have it work with all tables
@Sinnbeck Oh I effectively didn't thought about having this functionality directly with other tables. I will definitely need a form to handle this for each model. But with a morph table I think that it's not possible to do differently than with a json column, unless it contains all fields from all tables.
@vincent15000 correct if you want it to work with multiple tables, json is the way to go :)
@Sinnbeck thank you for your advice, I will think about all this and I will tell you what is my choice
@vincent15000 good idea. My suggestion was only ideas. Best to think it over to see what makes sense for your project :)
@Sinnbeck perhaps only ideas, but I think very good ideas ;)
But normally I don't like json columns, but if it's only for storing that data and you never need to search it, it should also be fine
@Sinnbeck absolutely no search on these datas, that's why I suggested the date in another field because there will be a search on the date
Like @sinnbeck , I should
not use json data (for search)
not pollute the data table with "rules"
I should create only one table "data_actions" with the fields
and of course always a cron job.
Hi @sr57 yes it's not a good idea to pollute the table with rules, but your suggestion let me think that the rules should be applied on all the table, whereas I need to apply them on only certain lines in the table
Right, this should be better
- table name
- table field
- action (ex 'code1' for set to null at date)
- criteria (to launch this action)
- parameter1 (ex date to set to null for action 'code1')
If no criteria can be defined (users select some specific records), I should choose @sinnbeck 's solution.
In fact I just summarize the 2 main best practices given by @sinnbeck
Having a "action table" per table or a general one is just a "mechanical" decision on how to code and as usual there is no absolute best choice.
criteria can also be "hard coded" in the action code, an other "mechanical" decision.
@sr57 except the fact not to pollute the data table, it would have been a good idea with a json column as I don't need any search on this field
@sr57 it would be interesting to put not only a date but a frequency : one a year every 12-31 set these fields to null
No limitation of the type of rule, the number of parameters ... and last but NOT LEAST , not customer dependent.
Please or to participate in this conversation.