I am creating some tables where I want to store the time when a record was created and when it was last updated. I thought I could have two timestamp fields where one would have the value CURRENT_TIMESTAMP and the other would have CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP. But I guess I can't do this because you can have only 1 timestamp field with a default value in a table?
How would you recommend I get and store the two times? Thanks!
A good way to create fields like 'created' and 'updated' is
CREATE TABLE `mytable` (
`id` INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
`created` TIMESTAMP DEFAULT '0000-00-00 00:00:00',
`updated` TIMESTAMP DEFAULT now() ON UPDATE now(),
`myfield` VARCHAR(255)
);
And its necessary to enter nulls into both columns during "insert":
INSERT INTO mytable (created,updated,myfield) VALUES (null,null,'blablabla');
And now, in all updates, the 'updated' field will have a new value with actual date.
UPDATE mytable SET myfield='blablablablu' WHERE myfield='blablabla';
Source : http://gusiev.com/2009/04/update-and-create-timestamps-with-mysql
As of MYSQL version 5.6.5 you can do this using DEFAULT and ON UPDATE. No triggers are needed.
ts_create TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
ts_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
You can have two columns of type timestamp in one table.
The following works for MySQL 5.0
create table t
(
id integer,
created_at timestamp default current_timestamp,
updated_at timestamp
);
I think you are confusing this with SQL Server (where timestamp is not really a "time stamp" and there is indeed a limit on a single "timestamp" column)
Edit: But you will need a trigger to update the update_at column each time the row is changed.
As far as I know, there's no workaround for that restriction. You'll need to manually set (at least) one of the timestamps, the easiest way is just add updated = NOW() to the UPDATE-query.
You'll need two columns: CREATE_TIME and UPDATE_TIME.
You might want to add CREATE_USER and UPDATE_USER.
Perhaps you'd want to have a 1:many relationship with name of column changed, old and new values.
It's all part of change data capture. You could have CDC tables that are updated using triggers.
I would leave the current timestamp the way you suggested and fill in the created_at field with current date on insert.
Related
I am working with a timesheet app, used by users from multiple timezones. I am trying to introduce a unique constraint, that only allows users to clock_in or clock_out once per day in the local timezone.
Please refer to the following table declaration:
Table "public.entries"
---------------------------------------------
Column | Type |
---------------------------------------------
id | bigint |
user_id | bigint |
entry_type | string | enum(clock_in, clock_out)
created_at | timestamp(6) without time zone |
But little lost on how to handle the timezone-aware uniqueness.
Update:
I am considering 0:00 hrs to 23:55 hrs of local time zone as day.
User's timezone is stored in the users table but can move to the entries table if it helps with constraints.
I misread the question and wrote a bad answer, so here's a new one...
I assume this is a typical client-server-db setup. You need to obtain the local time zone from the client that's clocking in/out the user; Postgres doesn't know what it is. We'll figure out the user's local date from that and store it. Then we'll have a uniqueness index on <user, local date>.
I thought there'd be fancier ways to do this by storing the timestamptz with a separate time zone col and calculating the date within the uniqueness index, but Postgres doesn't allow us to use date_trunc within an index. So we're going to denormalize just a little and make things a lot easier with this additional date col.
CREATE TABLE clock_in (
user_id bigint NOT NULL,
created_at timestamptz NOT NULL, -- stores microseconds since epoch
local_date date NOT NULL, -- stores the <year, month, day> in whatever timezone the user clocked in from
-- optional for bookkeeping purposes: time_zone text NOT NULL,
UNIQUE(user_id, local_date)
);
Take a look at the official date/time type docs for further explanation of the above. IMO you shouldn't rely on DB constraints to reject bad user input. They're more of a second line of defense meant to ensure a self-consistent database. First your server should query the last clock-in and error out if it was in the same day, and also error if there was no clock-in that day. You'll be able to yield more useful error messages that way. Then you can insert...
INSERT INTO clock_in(user_id, created_at, local_date) (
SELECT 1, now(),
(date_trunc('day', now() AT TIME ZONE 'insert_users_timezone_here'))::date
);
Usage example for a client who has indicated it's in the PST timezone:
me=# CREATE TABLE clock_in ( user_id bigint NOT NULL, created_at timestamptz NOT NULL, local_date date NOT NULL, UNIQUE(user_id, local_date) );
CREATE TABLE
me=# INSERT INTO clock_in(user_id, created_at, local_date) ( SELECT 1, now(), (date_trunc('day', now() AT TIME ZONE 'PST'))::date );
INSERT 0 1
me=# INSERT INTO clock_in(user_id, created_at, local_date) ( SELECT 1, now(), (date_trunc('day', now() AT TIME ZONE 'PST'))::date );
ERROR: duplicate key value violates unique constraint "clock_in_user_id_local_date_key"
DETAIL: Key (user_id, local_date)=(1, 2022-04-13) already exists.
me=# INSERT INTO clock_in(user_id, created_at, local_date) ( SELECT 1, now(), (date_trunc('day', now() AT TIME ZONE 'PST' + interval '10' hour))::date );
INSERT 0 1
me=#
Then you'd do the same for clock-outs.
Using timestamptz instead of timestamp is deliberate. You should almost never use timestamp, for reasons other answers describe well.
Firstly, you'll probably want to use a native datetime datatype and a range one at that, e.g. tstzrange (with timezone) / tsrange (without timezone) – they allow you to natively store a start and end time – see https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-BUILTIN
You can optionally add an exclusion constraint to ensure no two shifts overlap – see: https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-CONSTRAINT if that's all you really want to ensure, then that might be enough.
If you definitely want to ensure there's only one shift starting or ending per day, you can use a function to derive a unique index:
create unique index INDEX_NAME on TABLE_NAME (date_trunc('day', lower(column_name)))
For your example specifically:
create unique index idx_unique_shift_start_time on entries (user_id, date_trunc('day', lower(active_during)))
create unique index idx_unique_shift_end_time on entries (user_id, date_trunc('day', upper(active_during)))
These two indexes take the lower or upper bounds of the range (i.e. the start time or end time), then truncate to just the day (i.e. drop the hours, minutes, seconds etc) and then combine with the user_id to give us a unique key.
If I have a postgresql table like:
CREATE TABLE IF NOT EXISTS public.time_series
(id serial PRIMARY KEY,
variable_id integer NOT NULL,
datetime timestamp with time zone NOT NULL,
value real NOT NULL,
edit_datetime timestamp with time zone NOT NULL DEFAULT now())
Im not having any constrains here except the primary key. For now..
And i want to have the option to either UPDATE OR INSERT new data where it is essentially the same variable for the same datetime. So that I can choose to either overwrite or just have a new version.. How do a proceede to do that?
Without constrains and if I want to INSERT some data; I do some WHERE NOT EXISTS where i make sure that the new data does not correlate with a row that has the same variable_id, datetime, and value. And it works just fine.
Now if the case is that I want to UPDATE if it exists and else INSERT I make a CONSTRAINT like:
ALTER TABLE public.time_series
ADD CONSTRAINT unique_comp UNIQUE (variable_id, datetime)
And updates the row if there is a conflict and INSERT if there is non.
And it works just fine..
But, again, what if I for some variables wants pervious "versions" where i can see them based on edit_datetime and want some other variables to be overwritten with the new data? Currently one way rules out the other one.
BR
When I use the PostgreSQL 9.5 hstore() construction function on a row object in a query, it seems to only return columns in that row that are the text or integer datatypes. I can see that my timestamp and character varying columns are by default omitted from the HSTORE object that comes back.
In PostgreSQL 9.3 constructing a hstore object would include timestamp and character varying columns of the row as well, how can I get this behavior back?
Specifically my table's DDL looks like:
CREATE TABLE public.sessions
(
id integer NOT NULL DEFAULT nextval('sessions_id_seq'::regclass),
session_id character varying(255) NOT NULL,
data text,
created_at timestamp without time zone,
updated_at timestamp without time zone,
CONSTRAINT sessions_pkey PRIMARY KEY (id)
)
WITH (
OIDS=FALSE
);
Below is the output of running a hstore constructor; note that the session_id, created_at, and updated_at columns (keys) do not get added to the hstore even when their values are not null:
select hstore(sessions.*) from sessions limit 1;
hstore
---------------------------------------------------------------
"id"=>"15435216", "data"=>"DjfBv="
(1 row)
No. All columns should be included. Even with NULL values. (I just tested to verify.)
Maybe you are inadvertently using a different table with the same name in a different schema?
Aside: you can simplify to (equivalent):
SELECT hstore(sessions) FROM public.sessions LIMIT 1;
I schema-qualified public.sessions to make sure the right table is used.
I assume you are aware of the role of the schema search path?
How does the search_path influence identifier resolution and the "current schema"
I am writing a program to help me keep track of my day to day life, and I want one of the fields to be a "date" field that will automatically update. What specifically do I do in SQLITE 3? Something like....
create table day_to_day(
date field
miles_ran INTEGER
food_eaten TEXT
)
How about:
CREATE TABLE day_to_day(
id INTEGER PRIMARY KEY AUTOINCREMENT,
t TIMESTAMP DEFAULT CURRENT_TIMESTAMP
miles_ran INTEGER
food_eaten TEXT
);
which would give you a column called t with the type TIMESTAMP, as a alternative you could also use this:
CREATE TABLE day_to_day(
id INTEGER PRIMARY KEY AUTOINCREMENT,
t DATE DEFAULT (datetime('now','localtime')),
miles_ran INTEGER
food_eaten TEXT
);
Maybe you can use this :
CREATE TABLE table_test (
...
date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
or
CREATE TABLE table_test (
...
date DATE DEFAULT (datetime('now','localtime')),
);
This is a good reference : sqlite database default time value 'now'
You can read what the docs have to say about it: SQLite datatypes, scroll to section 1.2.
The gist of it is, you can either use TEXT, REAL, or INTEGER, and then use the corresponding Date/Time function to access it.
I have a date column in my table. When I perform an update query on the rows, each time the date gets refreshed to the current date. I have set date's default value to CURRENT_TIMESTAMP but why is this happening each time?
UPDATE
My create query:
CREATE TABLE `ACCOUNTS` (
`id` bigint(7) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(30) DEFAULT NULL,
`date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`status` varchar(1) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1234567 DEFAULT CHARSET=latin1
It's probably something to do with date being a keyword. try changing it to some_date. Was CURRENT_TIMESTAMP intentional?
When you set the default value to CURRENT_TIMESTAMP, sql will insert the current time stamp at the time of creating new record only and will never update it unless you update it yourself. Refreshing will not update the timestamp
In case you use a MariaDB, this documentation page https://mariadb.com/kb/en/library/timestamp/ may have some surprising information for you:
"The timestamp field is generally used to define at which moment in time a row was added or updated and by default will automatically be assigned the current datetime when a record is inserted or updated. The automatic properties only apply to the first TIMESTAMP in the record; subsequent TIMESTAMP columns will not be changed."
Hope this bit helps the next developer who runs into this fantastic feature...