Opened 14 years ago
Last modified 14 years ago
#1512 closed enhancement
Add support for datetime annotation types — at Version 9
Reported by: | Nicklas Nordborg | Owned by: | Nicklas Nordborg |
---|---|---|---|
Priority: | major | Milestone: | BASE 2.16 |
Component: | core | Version: | |
Keywords: | Cc: |
Description (last modified by )
This is a rather big change and will have effect in other parts of BASE as well. Here is a list of things that we need to do.
- Add a new table for storing datetime values and a subclass to
ParameterValues
to handle it. - Add a new option to the
Type
enumeration. - Update the gui so that it is possible to add datetime values
- Update the query api so that it is possible to search for datetime values
- There are probably some effects also on the plug-in api since the
Type
enumeration andParameterValues
class are used by plug-in parameters as well. I'll have to investigate the effect and maybe add a specific ticket for adding datetime support to the plug-in system if the work required is substantial. - There may be similar effects on "extendable" classes (eg. reporters, users and raw data).
- Update the annotation importer so that it can import timestamp values. I am not really sure how it handles date values right now. It may work if the date values are in
yyyy-MM-dd
format, but it has no support for specifying a different format. - Check and update documentation
- More...?
Change History (9)
comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Oh no... what a mess... I have to correct myself on the previous comment. It is possible to store datetime values with the current BASE release and it is not very complicated.
By changing the BASE->Preferences->Date format
setting to a template that includes time placeholders (for example yyyy-MM-dd hh:mm:ss
) it is possible to enter datetime values and the time part will be parsed and stored in the database. It messes up the query api though, since it will not match anything if not the exact date+time (including seconds) is entered as a search condition. Other users that hasn't changed the 'Date format' option will not be able to find any datetime values at all (except 00:00:00) since the time part is discarded before the query is made.
I think the "mess" needs to be cleaned up and they best way to do that is to make sure that no time part is getting into date-only values. Eg. we need one table for storing date-only values and one table for storing datetime values.
comment:4 by , 14 years ago
Description: | modified (diff) |
---|
comment:5 by , 14 years ago
(In [5422]) References #1512: Add support for datetime annotation types
Adds a new data class/table for storing datetime parameters (=timestamp in the SQL world). The schema update changes the existing DateValues table to only store dates.
Added Type.TIMESTAMP to the Type enumeration.
This is basically 1) and 2) in the ticket description.
comment:6 by , 14 years ago
comment:7 by , 14 years ago
(In [5424]) References #1512: Add support for datetime annotation types
Makes it possible to use TIMESTAMP for regular list columns. Added support for searching on the date part to the query api.
Changes all existing tables with date+time data to use TIMESTAMP instead.
This is half of 4) in the ticket description. It is still not possible to search on TIMESTAMP annotations.
comment:8 by , 14 years ago
(In [5429]) References #1512: Add support for datetime annotation types
Changed the approach used to search for date/timestamps. By using cast(value as date)
we can avoid all special cases when searching for a date among timestamp values. This affects the query api for all regular timestamp columns and it is now also possible to search for timestamp annotation values.
comment:9 by , 14 years ago
Description: | modified (diff) |
---|
Hmm... it seems like the table used to store dates is actually using a 'timestamp' column so theoretically it should be possible to use the existing table to store datetime values. And some (but not all) parts of the core api already allows the time part to be stored for date values. The main exception is that all string conversions to/from dates don't handle time and most of the gui is about string handling. I am trying to figure out what is the best:
The latter is "cleaner" and is more correct according to the current documentation. The ability to store the 'time' part can be considered a bug. On the other hand, converting the existing table is an incompatible change which will cause data loss if someone is storing datetimes in it. It's not that likely though, since it can't happen with the official BASE release.