It still doesn’t make sense. Obviously your whole explanation hinges very heavily on what exactly you mean when you say “not used/handled” . Depending on your specific use case this could mean anything. As with any code related question, there’s only so much that people who haven’t seen your code can do to help. I think the easiest way to avoid this confusion is to just show some code so we are all on the same page about what the issue is.
I am still confused about what OP is looking for. Even in typescript, if a new field is added and not used in other places, compilation will fail. Unless OP explicitly marks the field as optional.
There’s also the possibility that the codebase is littered with the “any” keyword (I’m not saying OP is doing it but I’ve definitely seen plenty of codebases that do this). If someone says they’re using typescript but their code is full of “any” keywords, they’re not using typescript. They’re just using plain JavaScript at that point.
The select after the update is to check if the update went through properly. You can have more selects before the update if you wanted to.
It actually turned out to be easier than I thought.
The infrared reader (arduino code) is based on
https://github.com/Arduino-IRremote/Arduino-IRremote
The code running on my raspberry pi was written in Java using spring boot which is probably overkill but I am more comfortable with java than python so I used
https://github.com/Fazecast/jSerialComm
to read data from the pi’s usb port and just sent instructions to the unified remote server which does most of the heavy lifting. I used
as a reference along with some verbose logging on the unified remote server to see what codes needed to be sent over the rest api.
Happy to help you along if you want to give this a go :)
I use it as a media remote for my computer via infrared. IR sensor sends analog data to an arduino which converts it to digital and sends it to a raspberry pi which then invokes commands to control media on my computer by invoking rest apis on a “unified remote” server running on the computer.
On thinking about this a bit more, I feel like you may be expecting the system to handle situations where your business requirement needs the new field to be used now, but used to work without this field before. Based on the example you provided, I am imagining something like a getTasksForUser functionality which previously might have just been filtering on userId but if the business now says that this functionality should now return tasks sorted by priority, you expect the system to somehow know the business requirement and force the developer to use this new priority field ?
If that’s what you’re hoping for, the problem is harder to solve although not impossible. Assuming the example as above , you could maybe just inject the priority field at the data access layer . Another way would be to make the modified entity private and expose a facade with helper functions that are exposed. Now when code that previously used to rely on the entity inevitably breaks , you can replace those usages with usage specific functions exposed from the facade and since the entity is now accessible only from the facade, you can easily update all usages within the facade and make sure no one can miss passing the priority field since the entity is private to the facade and all functions in the facade are known to use the new field.