For a while I've been thinking about overhauling the database structure, specifically some data types. Currently the date of flight as well as all logged times are logged as TEXT/VARCHAR(32). I suppose you went down this way to circumvent weird rounding problems when using floats for example. However, I think it would be best to think about other ways of saving this data.
Currently aggregating data is difficult to do on a database level, i.e. it is necessary to query lots of rows and then programmatically parse the times to sum them for example. As the datasets grow larger I think this might become more problematic (and less elegant imho). Same goes for filtering based on date.
My suggestion would be to save the logged times in minutes as INTs. I just found out that SQLite doesn't have a native date format, so I suppose the date might have to stay as is.
Of course a change like this would need lots of changes and testing before implementing, so I don't expect we implement this anytime soon.
Mostly I just wanted to put forward this idea and I'm interested in your thoughts @vsimakhin . Perhaps you've already thought about this and decided against it. Of course I can help or start a branch to start working on this if you're interested. Let me know ;)
For a while I've been thinking about overhauling the database structure, specifically some data types. Currently the date of flight as well as all logged times are logged as TEXT/VARCHAR(32). I suppose you went down this way to circumvent weird rounding problems when using floats for example. However, I think it would be best to think about other ways of saving this data.
Currently aggregating data is difficult to do on a database level, i.e. it is necessary to query lots of rows and then programmatically parse the times to sum them for example. As the datasets grow larger I think this might become more problematic (and less elegant imho). Same goes for filtering based on date.
My suggestion would be to save the logged times in minutes as INTs. I just found out that SQLite doesn't have a native date format, so I suppose the date might have to stay as is.
Of course a change like this would need lots of changes and testing before implementing, so I don't expect we implement this anytime soon.
Mostly I just wanted to put forward this idea and I'm interested in your thoughts @vsimakhin . Perhaps you've already thought about this and decided against it. Of course I can help or start a branch to start working on this if you're interested. Let me know ;)