I am trying to create a table on a mysql server with a bit column and a default value. Here the responsible changelog part:
This results in the following sql beeing executet:
CREATE TABLE `RM_Benutzer` (
`BenutzerId` INT AUTO_INCREMENT NOT NULL,
`BenutzerName` VARCHAR(255) NOT NULL,
`PasswordDoesNotExpire` bit DEFAULT 1 NOT NULL,
);
The Default value is now 1 on the db. It should be 0.
I have deleted some columns to make it clearer. So if there are any syntax errors or inconsistencies, it’s because of that. I can assure you, that the code works.
I think, from what I have found on the web and from the .xsd files, that “false” should be the correct value. And it works in liquibase 1.9. So I would consider this a bug, until someone tells me what I am doing wrong.
Yes, I do. I am less concerned about storage requirements as I am concerned about data type consistency. If I want to represent a boolean a bit is exactly what I need. A tiny int can have a lot of other values, which are invalid as a boolean. It can have any number in (0, 255). This would mean, I then had to create check constraints or, on a mysql db, triggers, to check that the values in the field are only in the range of (0, 1). Alternatively I could argue, that anything other than 0 is true, or I could argue that anything other than 1 is false. Both are valid and make sense depending on the circumstances you use it. If multiple developers work on a project one might choose one logic and the other might choose another logic. (This is a fact of live)
Additionally, any tools (I have) used to auto map between the db and an object structure will automatically interpret a bit as a boolean. Where a tiny int will result in a byte or some other integer type.
Now for the main point: Liquibase still makes a mistake and that is what I wanted to communicate with my post. So type discussions (although sometimes interesting) are beside the point.
It found the problem and it shoudl be fixed in trunk for the next release. It isn’t that true is false and false is true, it just looked like false was true…
Yes, I do. I am less concerned about storage requirements as I am concerned about data type consistency. If I want to represent a boolean a bit is exactly what I need. A tiny int can have a lot of other values, which are invalid as a boolean. It can have any number in (0, 255). This would mean, I then had to create check constraints or, on a mysql db, triggers, to check that the values in the field are only in the range of (0, 1). Alternatively I could argue, that anything other than 0 is true, or I could argue that anything other than 1 is false. Both are valid and make sense depending on the circumstances you use it. If multiple developers work on a project one might choose one logic and the other might choose another logic. (This is a fact of live)
Additionally, any tools (I have) used to auto map between the db and an object structure will automatically interpret a bit as a boolean. Where a tiny int will result in a byte or some other integer type.
Now for the main point: Liquibase still makes a mistake and that is what I wanted to communicate with my post. So type discussions (although sometimes interesting) are beside the point.
You’re right about liquibase in your main point, i was just interested in “type discussion” topic :), i’m just a user here, not a developer.
I personally don’t like this type because you have to always remember about its “binary” nature. For example this query
INSERT INTO bit_table SET id = '0'
will insert 1 instead of 0 in BIT(1) field because ord('0') is 48 which is much bigger than 1. For restriction of possible values I'd use ENUM in your case, so you can define your values as FALSE, TRUE or maybe even in your domain logic terms as ENABLED, DISABLED and etc.
