+++ This bug was initially created as a clone of Bug #51523 +++
LibreOffice does not support the SQL INTERVAL datatype. That is the datatype to store time *durations*, rather than a point in time (like DATE, TIME, TIMESTAMP).
Our embedded HSQLDB 1.8 also does not support it, but that is no reason not to support it cleanly when connecting to database backends that *do* support it.
Places that need to be changed:
1) offapi/com/sun/star/sdbc/DataType.idl needs a value for INTERVAL
2) connectivity/inc/connectivity/FValue.hxx: class ORowSetValue needs to be
adapted to handle values of that type. Also connectivity
source/commontools/FValue.cxx and undoubtedly many other places, such as
Changed status to "NEW"
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Adding self to CC if not already on
Migrating Whiteboard tags to Keywords: (easyHack, difficultyInteresting, skillCpp, skillSql)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
I could not add INTERVAL selection to datatypes list. Because I could not find associated .ui file. How can i find? Can you help me?
(In reply to kerem from comment #6)
> I could not add INTERVAL selection to datatypes list. Because I could not
> find associated .ui file. How can i find? Can you help me?
Before starting to change UI, it needs to be supported in the backend. See comment 0, "places that need to be changed". Did you do that already?
(In reply to Lionel Elie Mamane from comment #7)
> Before starting to change UI, it needs to be supported in the backend. See
> comment 0, "places that need to be changed". Did you do that already?
Yes, i changed in necessary places. But i am not sure. Because i still haven't find INTERVAL data type. Shall I commit my changes?
Latest versions of HSQLDB seems to support interval data types. Should it be upgraded first?
(In reply to Gökay ŞATIR from comment #9)
> Latest versions of HSQLDB seems to support interval data types. Should it be
> upgraded first?
No, we want to remove embedded HSQLDB completely in favour of Firebird.
Is there an ongoing discussion about which db system to choose? Like this one:
Or is the decision is made already?
I think SQLite could again be the candidate. Its latest versions support multiple reads at the same time, it handles multiple connections well.
SQLite just needs a wrapper for data types, which can be implemented on top of it.
Also, it has amalgamation, i personally find that feature valuable.
(In reply to Gökay ŞATIR from comment #11)
> Is there an ongoing discussion about which db system to choose? Like this
> Or is the decision is made already?
> I think SQLite could again be the candidate. Its latest versions support
> multiple reads at the same time, it handles multiple connections well.
> SQLite just needs a wrapper for data types, which can be implemented on top
> of it.
> Also, it has amalgamation, i personally find that feature valuable.
There is no ongoing discussion. The decision was made long ago. Since then, there have been multiple Google Summer of Code projects and also TDF contracts to bring embedded Firebird into a production-ready status.
I highly recommend you to contribute to the meta reports:
There are some fundamental data type differences between HSQLDB and Firebird, but the upcoming Firebird 4.0 will solve a couple of these and hopefully a future version will solve more. This would make it easier to migrate existing database files from HSQLDB to Firebird.
Hopefully we will see 4.0 during the second quarter of 2020.
Thank you for your comment. I started to read bug reports and will try to debug & contribute to the progress.