DB schema uses datetime with 1-second granularity

[trevorcarlson]

The currently default datetime type in MySQL uses second granularity.

Expanding to sub-second granularity might allow us to re-enable checks for duplicate entries. Adding an integer parameter to the DATETIME type in the schema allows one to specify the number of digits of resolution. See (https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html) for more details.

[aohren]

Agreed. I'd actually even like to change it to a plain long integer type.
Though in actual practice, sampling times >1 sec might generate a
ridiculous amount of data that's not very useful.

On Wed, Mar 19, 2014 at 3:15 PM, trevorcarlson [email protected]:

The currently default datetime type in MySQL uses second granularity.

Expanding to sub-second granularity might allow us to re-enable checks for
duplicate entries. Adding an integer parameter to the DATETIME type in the
schema allows one to specify the number of digits of resolution. See (
https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html) for more
details.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[trevorcarlson]

Yep, I completely agree, but there might be times when you want to log for a short high-res burst. Just an idea, nothing needed right now. :)

On Mar 19, 2014, at 8:28 PM, Adam Ohren [email protected] wrote:

Agreed. I'd actually even like to change it to a plain long integer type.
Though in actual practice, sampling times >1 sec might generate a
ridiculous amount of data that's not very useful.

On Wed, Mar 19, 2014 at 3:15 PM, trevorcarlson [email protected]:

The currently default datetime type in MySQL uses second granularity.

Expanding to sub-second granularity might allow us to re-enable checks for
duplicate entries. Adding an integer parameter to the DATETIME type in the
schema allows one to specify the number of digits of resolution. See (
https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html) for more
details.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

—
Reply to this email directly or view it on GitHub.

[aeratek]

Might be worth checking out what the Conveyal folks implemented for their Android platform, since we know they did protocol buffers. I believe it's also a github project; the links can probably be found through Kevin Webb's posts on conveyal.com

On Mar 19, 2014, at 2:36 PM, trevorcarlson [email protected] wrote:

Yep, I completely agree, but there might be times when you want to log for a short high-res burst. Just an idea, nothing needed right now. :)

On Mar 19, 2014, at 8:28 PM, Adam Ohren [email protected] wrote:

Agreed. I'd actually even like to change it to a plain long integer type.
Though in actual practice, sampling times >1 sec might generate a
ridiculous amount of data that's not very useful.

On Wed, Mar 19, 2014 at 3:15 PM, trevorcarlson [email protected]:

The currently default datetime type in MySQL uses second granularity.

Expanding to sub-second granularity might allow us to re-enable checks for
duplicate entries. Adding an integer parameter to the DATETIME type in the
schema allows one to specify the number of digits of resolution. See (
https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html) for more
details.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.