Closed cedricbriandgithub closed 2 years ago
Chose option2 and changed the template accordingly
@cedricbriandgithub I don't know exactly why fi_date was added. fi_year was a way to have "ecological/season years", and it relates to both series and other sampling, that's why it was in t_fish_fi table and not in t_fishseries_ser. fi_date can make sense but will it be available for all data? If yes, we can indeed remove fi_year
@elfunesto I had the same though, but then I considered that the values attached to a series might be marked as one year, but in practise correspond to year -1 => year I have currently removed the year column for other sampling as I seem to recall that the sampling date was present
Did I break something while merging ?
CREATE TABLE datawg.t_fish_fi( fi_id SERIAL PRIMARY KEY, fi_date DATE NOT NULL, fi_year INTEGER NOT NULL, fi_comment TEXT, fi_lastupdate DATE NOT NULL DEFAULT CURRENT_DATE, fi_dts_datasource varchar(100), CONSTRAINT c_fk_fi_dts_datasource FOREIGN KEY (fi_dts_datasource) REFERENCES "ref".tr_datasource_dts(dts_datasource) ON UPDATE CASCADE );
We have both fi_date, and fi_year in the t_fish_fi table, I'm not sure why, I think that fi_year has to be removed, but maybe this is to relate to dataseries (and now I'm thinking about this we should have it for those series that span seasons, but in that case why is it not in t_fisheries_fiser ? Option1 => remove fi_year from table Option2 => remove fi_year from table t_fish_fi but add it to fishseries fish_ser ... we need to correct the templates for series only. This is my preferred choice, and I've started developing along those lines. Option3 => keep it there, but I can't puzzle why .... and we need to fix both series and dcf sampling template.