I would like to append two timestamp columns to an existing table.
CREATED_TSTMP would be populated with the current timestamp when a record is inserted and LAST_UPD_TSTMP would be updated automatically when a record in the table gets updated.
I would like to do this without having to modify existing queries.
I have the following DDL statements:
ALTER TABLE XXX ADD CREATED_TSTMP TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP ;
alter table XXX add column LAST_UPD_TSTMP timestamp not null generated by default for each row on update as row change timestamp ;
However once the columns are appended, this will cause an existing query with the following syntax:
INSERT INTO XXX VALUES(?,?,?,?,?,?,?,?,?,?)
to fail with
The number of values assigned is not the same as the number of
specified or implied columns or variables..
Is there any way around this problem without having to inspect all of the existing queries (there are hundreds of them...)
If you add the IMPLICITLY HIDDEN option when creating the columns, they will be ignored by the SQL statements unless you explicitly mention these columns.
PS. I'm assuming you are on a sufficiently recent version of DB2, because of your using row change timestamp. To avoid ambiguity, you should indicate the DB2 version and platform in question.
Related
I have a Postgres table with certain data, let's say I have 3 columns at the beginning:
name
age
gender
Name1
31
F
Name2
18
M
Name3
22
F
Later on I want to add a new field created_date to record when a user is created and meet 2 sceanrios:
For the existing users, leave the fields empty
For the new users, the field created_date is required and can't be NULL.
Now I can't find a way to how to define "empty" since it can't be null if I add created_date NOT NULL like below query, but the same time I don't want to add DEFAULT xxx since the time is inaccurate.
ALTER TABLE `users`
ADD `created_Date` DATETIME NOT NULL
DEFAULT '2023-02-03 00:00:00'
Can anyone help to define the "empty" in this case?
There are only three options:
Make the new column not nullable
Make the column nullable and use a default date for all existing entries like 01.01.2000. You can set a default value on the column or do an update after adding the column. In the second case the not null needs to be added (with alter table statement) to the column after the update statement.
Create a complete new Table and use it to insert new entries. To read all values together (old entries without date column and new columns with date column) you can make a View which combines the two tables with a union all. This case requires adjustments in your Application and a good thinking about to not have duplicate entries in both tables. And of course the sequences needs to be adjusted aswell. I would not go this way.
Unfortunately there is no other option if the column needs to be not null.
I'd recommend instead:
ALTER TABLE users
ADD COLUMN created TIMESTAMP WITH TIME ZONE NOT NULL
DEFAULT '1970-01-01 00:00:00 UTC';
ALTER TABLE users
ALTER COLUMN created SET DEFAULT now();
That's because:
The column name "current_date" is misleading. This is a timestamp, not just a date.
You should always use "timestamp with time zone" for timestamps, or you'll otherwise have various bugs, like values going backwards, being duplicated, jumping forward, being interpreted differently depending on the client's time zone etc.
This will fill currently existing rows with the timestamp '1970-01-01 00:00:00 UTC', which is immediately recognized as a timestamp "0", so called "epoch time", making it obviously fake, but still older than any newly created.
After that, changing the default to now() will make new rows fill the timestamp automatically and correctly, when the client will either skip the column or will use DEFAULT as value.
if a table have default value on a column for e.g.
create table emp
(
flag smallint default 1
)
so is there any impact of this default column in bulk import , if I am not using in insert statement.
According to the docs:
Before 11:
Adding a column with a default requires updating each row of the table (to store the new column value). However, if no default is specified, PostgreSQL is able to avoid the physical update. So if you intend to fill the column with mostly nondefault values, it's best to add the column with no default, insert the correct values using UPDATE, and then add any desired default as described below.
source
11 and after:
From PostgreSQL 11, adding a column with a constant default value no longer means that each row of the table needs to be updated when the ALTER TABLE statement is executed. Instead, the default value will be returned the next time the row is accessed, and applied when the table is rewritten, making the ALTER TABLE very fast even on large tables. However, if the default value is volatile (e.g., clock_timestamp()) each row will need to be updated with the value calculated at the time ALTER TABLE is executed. To avoid a potentially lengthy update operation, particularly if you intend to fill the column with mostly nondefault values anyway, it may be preferable to add the column with no default, insert the correct values using UPDATE, and then add any desired default as described below.
source
If you take a look into the source for the generator/planner/optimizer/rewriter
( postgresql/src/backend/rewrite/rewriteHandler.c around line#1112, function build_column_default() ) :
The default value(or function, e.g. for serials) is fetched from the catalogs and added once to the query tree. So, the DEFAULT may even be more efficient than fetching separate values for all affected rows from one of the tables in query.
But you would have to measure the difference to be sure.
I have the following table:
Study id
Pepsi 1
Coke 2
Sprite 3
I need to add a new column timestamp in the above table. i.e, study creation time and date will be stored in this column. What value should I have set for existing rows? Or should the "Timestamp" column have a value only for newly created rows?
I have used the following query to add the new column:
alter table Study add Timestamp datetime
There is no way to tell you what value you should set for existing rows - that is up to you to decide. If you can somehow retrieve the creation time by piecing together other information, then perhaps you can do this one by one, or you could just leave the existing rows to NULL.
Setting a default like GETDATE() for the column, and setting it to NOT NULL, forces all of the existing rows to inherit the current date and time - and you won't be able to set those back to NULL. I'm quite opposed to using garbage token values like 1900-01-01 to represent unknown, and I also don't believe in modifying the code to say something like "if the date is October 8, 2013 then that's because we just didn't know." So I would suggest adding a NULLable column with a default:
ALTER TABLE dbo.Study ADD CreationTime DATETIME NULL DEFAULT CURRENT_TIMESTAMP;
GO
Note that if you leave the column nullable, then the DEFAULT constraint is only useful if DML never sets it to NULL. If an INSERT statement, for example, explicitly places NULL there, the default is ignored. A way around this is to use a trigger (just like you would handle an update):
CREATE TRIGGER dbo.StudyCreationTime
ON dbo.Study
FOR INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE s
SET s.CreationTime = CURRENT_TIMESTAMP
FROM dbo.Study AS s
INNER JOIN inserted AS i
ON s.StudyID = i.StudyID;
END
GO
what value should i have to set for previous studies
This would have to be defined by your business. This doesn't require a technical answer, so no one here can tell you what is right.
I have used below query to adding new column:
alter table Study add Timestamp datetime
This will work just fine, though this will allow nulls. I might suggest making this column non-null, adding a default, and changing the name of the column slightly since timestamp is a reserved word in SQL Server (a datatype that has not much to do with dates or times):
alter table Study add CreateDate datetime not null default current_timestamp;
Note that this will set all rows to the current date and time, so you may want to update them if you have more accurate data. Alternatively, simply create the column as nullable and existing rows won't get the default value, but rather null instead.
Another choice you might have to make is whether to use local time or UTC time (e.g. default getutcdate()). You might want to use the same time that your servers use or that other "CreateDate" columns use.
In Sql Server 2008, I have a table that is filled by a data provider application.
I want to keep an "INSERT_DATE" column on table, so that I can know the date the record is inserted.
In order to do this, I defined a default constraint on INSERT_DATE column which puts GETDATE() by default.
However, I don't want this column value to be overwritten by data provider application.
So, how can I disable insert into INSERT_DATE column?
(I cannot use computed column. Because Clustered Index uses INSERT_DATE field)
You could use an After Insert trigger. That way, whatever is inserted into that column for an inserted row you could update to the current date/time.
You probably don't want the column updates as well when the row is subsequently updated.
Your best bet is to use a trigger. You might not be able to throw an error if the application provides a value but at least you will be able to set it right by skipping the column in the insert you specify in your trigger.
I have a table in a database that represents dates textually (i.e. "2008-11-09") and I would like to replace them with the UNIX timestamp. However, I don't think that MySQL is capable of doing the conversion on its own, so I'd like to write a little script to do the conversion. The way I can think to do it involves getting all the records in the table, iterating through them, and updating the database records. However, with no primary key, I can't easily get the exact record I need to update.
Is there a way to get MySQL to assign temporary IDs to records during a SELECT so that I refer back to them when doing UPDATEs?
Does this not do it?
UPDATE
MyTable
SET
MyTimeStamp = UNIX_TIMESTAMP(MyDateTime);
If for some reason you do have to iterate (the other answers cover the situation where you don't), I can think of two ways to do it (these aren't MySQL-specific):
Add a column to the table that's an auto-assigned number. Use that as the PK for your updates, then drop the column afterwards (or just keep it around for future use).
In a table with no defined PK, as long as there are no exact duplicate rows, you can use the entire row as a composite PK; just use every column in the row as your distinguishing characteristic. i.e., if the table has 3 columns, "name", "address", and "updated", do the following:
UPDATE mytable SET updated = [timestamp value] WHERE name = [name] AND address = [address] AND timestamp = [old timestamp]
Many data access frameworks use this exact strategy to implement optimistic concurrency.
No, you should be able to do this with a single update statement. If all of the dates are yyyy-mm-dd and they are just stored in some sort of text column instead of DATETIME, you can just move the data over. SQL would be like:
ALTER TABLE t ADD COLUMN dates DATETIME;
UPDATE t set t.dates=t.olddate;
This shouldn't be dependent on a PK because MySQL can scan through each row in the table. The only time PK's become an issue is if you need to update a single row, but the row may not be unique.
You can generate values during a SELECT using the MySQL user variables feature, but these values do not refer to the row; they're temporary parts of the result set only. You can't use them in UPDATE statements.
SET #v := 0;
SELECT #v:=#v+1, * FROM mytable;
Here's how I'd solve the problem. You're going to have to create another column for your UNIX timestamps anyway, so you can add it first. Then convert the values in the old datetime column to the UNIX timestamp and place it in the new column. Then drop the old textual datetime column.
ALTER TABLE mytable ADD COLUMN unix_timestamp INT UNSIGNED NOT NULL DEFAULT 0;
UPDATE mytable
SET unix_timestamp = UNIX_TIMESTAMP( STR_TO_DATE( text_timestamp, '%Y-%m-%d' ) );
ALTER TABLE mytable DROP COLUMN text_timestamp;
Of course you should confirm that the conversion has been done correctly before you drop the old column!
See UNIX_TIMESTAMP() and STR_TO_DATE()