I agree with you. The immediate concern here is not performing calculations on the value, but that the string provided by avp is not necessarily what was contained in the database, which is unexpected behavior. And that's OK so long as the user is aware that the data could be truncated or padded with zeros, and the user will need to increase the precision and recompile, or use regex or transformations to get the desired substring. Clear documentation and change notes can prevent a lot of frustration.
Regards, *Calvin Ellison* Senior Voice Operations Engineer calvin.elli...@voxox.com On Wed, Mar 11, 2020 at 10:06 AM Brett Nemeroff <br...@nemeroff.com> wrote: > Calvin, > The issue is more about what you want to do with that data in the opensips > script. Are you really wanting to do floating point math in the script? Or > are you taking those floats (like GPS coordinates) and using them as string > values in a header. If that’s all you want to do, you should cast your > values as strings before they land in the AVP IMO. No need to support that > floating point format if you arn’t looking to do real-time precision math > IN the script. > > If possible, that math really should occur in the database. Easy enough to > do in a avp_db_query. > > On Wed, Mar 11, 2020 at 11:57 AM Calvin Ellison <calvin.elli...@voxox.com> > wrote: > >> >> What other use cases might there be for double type values? E911 or other >> things using GPS coordinates might be stored this way, but 8 digits are >> more than enough for that. >> >> _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
