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 notifications@github.comwrote:

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/kinisi/geoserver/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 notifications@github.com 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 notifications@github.comwrote:

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/kinisi/geoserver/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 notifications@github.com 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 notifications@github.com 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 notifications@github.comwrote:

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/kinisi/geoserver/issues/1 .

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