Edge case or poor planning

[dandy72]

kmoorevs wrote:

0: Datetime for a new reading must be greater than the previous reading datetime. 1: Meter reading must be greater than or equal to the previous reading.

Well, for one thing, if local time is being used to track those transactions, rather than UTC, then if you're in a timezone that observes DST, every transaction will be rejected for a period of an hour when the clock gets moved back...

[jmaida]

Use EPOCH timestamp that Unix/Linux uses. Make it 64 bit to make it last beyond 2038. Don't know what a meter reading is so no help there. It's been my experience that users will eventually find a way to break code. Just a question of accidental or on purpose.

[CodeWomble]

Option 4: Add a setting that is automatically added to the reading. This can be 0 for most machines and a sensible value for the machine you are 'hacking' Quick and dirty.

[kmoorevs]

dandy72 wrote:

if you're in a timezone that observes DST, every transaction will be rejected for a period of an hour when the clock gets moved back...

OK, you got me there. :laugh: Can you imagine an underpaid manager taking meter readings at 2AM on Sunday? :laugh: Thanks for the heads up, but I'm willing to take that risk. :laugh:

"Go forth into the source" - Neal Morse "Hope is contagious"

[kmoorevs]

:thumbsup: That's actually a pretty good idea. Thanks! :)

"Go forth into the source" - Neal Morse "Hope is contagious"

[honey the codewitch]

Overvalidation requires overtesting which itself causes more churn. That's the brutal irony of the situation. The other day I spent almost an entire day poring over a routine because the test for it was broken - but it wasn't even the test itself, but bad metrics in a font file i downloaded. I also can't count the number of times I've had to remove parameter validation as routines get nested inside the internals instead of being part of that API's surface area as things evolve, or to extend them with optional (read: nullable) parameters. But worse is a situation like you describe. It's not an edge case - and the reason for that is you don't know all the situations in which the machine can be reset, necessarily - or do you? What about an EMP? Ergo, it's a failure condition that's not being handled gracefully. Therefore, it's a design flaw, and one that would have been non-obvious to catch in the design phase. You got bit, only I don't think you did anything wrong, because erring on the side of overvalidating is better than the alternative, but honestly, I would have done your time validation at another level, like halt if the clock isn't greater than the last time you read it, and I would have skipped the transaction amount accumulation checking altogether barring a scenario you can think of where it's necessary. Can you pull it out? Can you adjust the clock code so it checks that the clock's good on start, instead of checking it where you are? That way all you theoretically have to do to restart it on a machine reset it set the clock. I'm flying blind here, so I may be talking out my backside, but all of this is just stuff that occurred to me.

To err is human. Fortune favors the monsters.

[englebart]

Sounds like your data model needs to track the PLC and the case as 2 separate entities. I think the new PLC should start as a new PLC-30 (0 initial start) placed in CASE-10. PLC-04 previously in CASE-10 is retired/scrapped. Just keep an eye on the collectors as they will find new ways to trick the cash control reports. Like entering negative currency on PLC-04 to balance what goes in their pocket!

[Sander Rossel]

I usually go for minimal validation for exactly the reason you describe. I ask myself, do I really need this value for the process to work? If so, it's required. And also, should a value have a maximum length for it to be saved in the database? If so, I add a maximum length. The latter is rarely a problem since I give my field lengths a value that's definitely high enough (usually something like four times the length I'd expect). And often I make a unique validation, like on a unique code or key. Other than that, anything goes (unless explicitly specified). If the data is wrong I can always tell my customer it's their data. Of course I can write an extra validation, but they should also validate their process so it won't happen again.

Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript

[jsc42]

kmoorevs wrote:

Meter reading must be greater than or equal to the previous reading.

I hope that the machine itself submits the reading. If it is read by an operative who then posts it, you have greater problems. I still submit my electricity meter reading 'manually' and have once got the digits wrong which gave an excessively high reading, followed by a much lower correct reading. Now my electric meter has an odometer style display that is in the 900000s and only has six digits; when it reaches 999999 it will roll back to 000000 - I am already worrying if my supplier will be able to cope with that. The flip side is that 'modern' design principles (XP - Extreme Programming) say you should only cater for the 'known' and not pre-guess the 'unknown'. It is called YAGNI "You Ain't Going to Need It" / "You Aren't Gonna Need It".

[dandy72]

In my defense, I had very little context to work with. This could be some automated system that's working on transactions coming in 24/7. Besides, it's an easy fix. Why risk it?

[Lost User]

I think that's up there with rolling back the odometer on a car. Create a new "machine account" (with maybe a link to the old one).

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I