Store bridge and device addresses as numbers

[pkqk]

I can't remember what sized integer they are but I would recommend storing them in the database and using them in the code as a number instead of a string.

The only time they need to be treated as a string is when you're displaying them for debugging or logging information and this could be done with another property on the DeviceCommand and BridgeCommand models or you could make a new column type that extended db.Integer that has a __str__ method that creates the hex string.

It became a problem in the ruby version as it was often being converted to and from a string a lot and it was difficult to refactor out as so much code used it.

[teh]

Hi Adam, nice tom meet you! I'm Tom, and I am currently rewriting the code. I'm storing the device and bridge address as an opaque string and I don't think it's going to be an issue. The addresses are used in two ways

1. for extracting the hardware XOR and
2. for comparison when figuring out where to send a message (equality only)

The first is self-contained, so unlikely to break. For the second it doesn't matter what the address looks like as long as we don't change its representation at any point. Does that make sense or am I misunderstanding your point?

Also: I already removed the bridge and device command models because we don't really need to keep commands in the database. They can call be handled in memory. The only thing I'd like to store is the "intent", e.g. "message BlaBla from user U to printer P".

[pkqk]

cool, you're on the right track then. The filling up the of the database was a massive problem when I started working on the old code. You may want some storage of current messages though, as if the server crashes and you can then get a response for a messages you don't know about anymore.

the address code was a bit more spread around previously and wasn't isolated. For purity I'd still suggest treating it like the number it is but if it's isolated to one part then it really doesn't matter at all.