I have a MariaDB version 10.2.13-MariaDB-10.2.13+maria~jessie, with a table ids. The table's create code is:
CREATE TABLE `ids` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`lastupdate` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, # for some reason this is being ignored
PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;
When the table is created, the lastupdate column's default value is not set. In fact, looking at the CREATE code in HeidiSQL, I see ... DEFAULT '' ....
Furthermore, the following query runs without error, but does not affect the table
ALTER TABLE ids
MODIFY lastupdate TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
whereas this one works completely fine
ALTER TABLE ids
MODIFY lastupdate TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00';
. What could be going wrong here?
Implementation detail: The database is being run inside a docker container trivially extended from the default mariadb image.
This is probably an issue with HeidiSQL (or this particular version of HeidiSQL), not an issue with MariaDB itself.
You can verify this by using the MariaDB client (mysql) and run your CREATE TABLE query and then:
SHOW CREATE TABLE ids;
Related
Use utc_current as default value in a field of an informix database table.
My idea is to do something like this, so that when that record is inserted or updated, the value is automatically increased since datetime or timestamp doesn't work for me.
CREATE TABLE tab1
(
id VARCHAR(128) NOT NULL,
update_ts integer DEFAULT dbinfo('utc_current') ,
modcount BIGINT,
);
I currently have the following tables in a database:
create table map (
id bigint not null unique,
zone box not null,
...
primary key(id)
);
create table other_map (
id bigint not null unique,
zone box not null,
...
primary key(id),
foreign key(id) references map(id)
);
I don't want to allow a new row to be inserted in other_map if there is a row in map whose id is equal to the new entry's id and their zone attributes overlap. I found this answer, which explains how to detect overlapping boxes, but I'd like to know how to (best) apply that in Postgres.
This is what I've come up with so far, using a trigger and a stored procedure:
CREATE OR REPLACE FUNCTION PROC_other_map_IU()
RETURNS TRIGGER AS $PROC_other_map_IU$
DECLARE
id bigint;
zone box;
BEGIN
SELECT map.id, map.zone INTO id, zone
FROM map
WHERE map.id = NEW.id;
IF zone = NEW.zone THEN
RAISE EXCEPTION '%\'s zone overlaps with existing %\'s zone', NEW.id, id;
END IF;
RETURN NEW;
END;
$PROC_other_map_IU$ LANGUAGE plpgsql;
CREATE TRIGGER TR_other_map_IU
AFTER INSERT OR UPDATE
ON other_map
FOR EACH ROW EXECUTE PROCEDURE PROC_other_map_IU();
Now obviously this is wrong, because it simply checks if the zone attributes are equal.
Thank you in advance for your input! Cheers!
Took me a while, but Postgres' geometric functions and operators (more specifically the && - or overlap - operator) do exactly what I wanted:
IF zone && NEW.zone THEN
I am using contao 4 but I had this problem already in version 3.
I have created a table with some columns. One of this column is marked as int(10) default NULL. Nothing special about that.
However: When I run my database upate, this column is always shown as changed.
ALTER TABLE `tl_products` CHANGE `tags` `tags` int(10) default NULL;
It doenst matter how often I press upate. This statement never disappears.
I already saw that at different other cases (e.g. when one writes default 0 instead of default '0'). Does anyone know how to fix this one?
The correct definition is
int(10) NULL
which should work in Contao. Your previous definition, int(10) default NULL is shorthand for int(10) NOT NULL default NULL, which makes no sense of course (thus it cannot be detected by Contao).
I'm doing a mass insert a la #chris-heald. If you're interacting with the database directly using raw SQL, do you need to provide the created_at and updated_at fields yourself or will you get that for free from postgres? I'm unclear whether it's Rails or postgres that does the automagical generation here.
ActiveRecord sets the updated_at and created_at values by itself, it doesn't set up the database to supply those values.
If you're doing a bulk insert through SQL then you have some options:
Assign them manually by using Time.now.utc.iso8601 to build the necessary strings. If you need greater precision in your timestamps then you can use strftime instead of iso8601 to build the strings.
Let the database do it by setting default values for those two columns. You could say:
alter table your_table alter column created_at set default now();
alter table your_table alter column created_at set default now();
to add the defaults, then do your bulk import, and then get rid of the defaults using:
alter table your_table alter column created_at drop default;
alter table your_table alter column created_at drop default;
You'd use ActiveRecord::Base.connection.execute to send those ALTER TABLEs into your database if you're doing all this from within Rails.
I have a table called messages and here is the table structure, I don’t want id is auto increment field but it should be a primary key for that table.
Here is table structure for messages
CREATE TABLE `messages` (
`id` INT(11) NOT NULL,
`user_id` INT(11) NOT NULL,
`text` VARCHAR(255) NOT NULL,
`source` VARCHAR(100),
`created_at` DATETIME DEFAULT NULL,
`updated_at` DATETIME DEFAULT NULL,
PRIMARY KEY (`id`)
);
while insert the data into table I am using below hash object
msg['id'] = 12345;
msg['user_id'] = 1;
msg['text'] = 'Hello world';
If I save this hash into messages table, id is not inserting
message = Message.new(msg);
message.save!
Rails is building insert sql with out id, so id value is not inserting messages table.
How insert the id value in table, This the insert sql rails build with out using id field
INSERT INTO `users` (`updated_at`, `user_id `, `text`, `created_at`) VALUES('2010-06-18 12:01:05', '1', 'Hello world', '2010-06-18 12:01:05');
Setting ID value is often useful when migrating from legacy data or - as I am doing right now - merging two apps while preserving FK integrity.
I just scratched my head for a while and it seems you have to set the PK value before calling save. After the record is saved, ActiveRecord ignores #id= or update_attribute . So while setting up the record from an attribute hash I use:
article = Article.new(attrs)
article.id = attrs["id"]
article.save!
You're working against the way rails works. ActiveRecord reserves the use of the id column and manages it for you.
Why should id not be an auto-incrementing column if it's the primary key?
Why do you need to control its value?
If you need an id column you can control yourself, add another one. It won't be the primary key, but you can make it a unique index too.