From now on @tipU will take this small growth into account and update your delegation every 30 seconds in the database.
Why doesn't @tipu just use vests to calculate stake instead of SP? Then, you can go off the ubiquitous value instead of passing around and persisting the converted value.
Because most users don't know what vests are - they delegate Steem Power so they would like to see that.
That doesn't change things. Use time as an example. Most people only know their timezones. Some places have DST. Some do not. We can't store D/T in all formats, so what we do is store/persist the ubiquitous value (UTC), and handle conversion on-on-the-fly through a formatter (date-time-formatters are pretty prevalent). Seems like the best thing to do in this situation would be to just use VESTS universally and use a formatter to show people the value they care about.
Well, converting to SP is really not a problem.
Exactly. It's an easy thing to do. Why schedule it every 30 seconds? Why not just convert at the time you use it? At the time you need to determine someone's delegation. Fetch the vests. Then, convert to the amount of SP it represents. Also, at the time you need to report SP information back to users, the same occurs. There's no real reason not to. However, scheduling a task to handle the conversion and persist it every 30 seconds does the following
Seems that you are unaware that vests -> SP conversion rate is changing every block (3 seconds). Basically vests translates to more SP over time.
That's not where 30 seconds comes from. You don't seem to be following me at all. This is just good programming practice. It has nothing to do with steem. It could be any software that @tipu is operating against. @tipu is what we're discussing.
You're right though. I should take into account the block update. Taking into account block update (every 3 seconds), this means that that conversion values persisted will only actually be good for 3 seconds. Which also means that only conversion values read within 3 seconds of the conversion being persisted will actually be accurate. That's the best case scenario (values are persisted nearly on or right after a block update). It's possible conversion values persisted just before (maybe 1 second) a block update. This would cause persisted conversion values to only be good for one second which would be your worst case scenario. IMHO, those are ideal conditions for on-the-fly conversion. Instead of persisting it.
Now that I reread this, it seems other values are affecting things as well. Updating values every 30 seconds turns records/documents/whatever into index entries because they can only live for 30 seconds. I think it's a good idea not to do this. Instead of updating the values every 30 seconds, store original values.
Thank you for your feedback but there are other reasons to update those values. For example I will be able to present them to the users and everyone likes to watch his investment grow in (almost) real time :)
Just trying to be helpful here. I assure you, you can get actual real-time, protect data from half-life, and reduce the number of extra tasks your app is doing by converting on-the-fly. It can be as easy as adding a decorator to your models that include VESTS which includes a formatter/converter. This way, you can get both values and be real-time accurate.