LINUX.ORG.RU

MySQL изменила схему лицензирования веток 5.0 и 5.1


0

0

Помимо того что MySQL больше не выпускает анонсы о новых версиях для пользовательских масс. Они изменили схему лицензирования веток 5.0 и 5.1 от "GPLv2 or later" к "GPLv2 only", т.е. это пока явный отказ от перехода на GPLv3. Также MySQl распространил авторское право на весь свой код, что позволяет компании изменить лицензию в любое время по желанию.

>>> Подробности

Ответ на: комментарий от Sorcerer

> Приведите, пожалуйста.


mysql> show create table x;
+-------+-----------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                                                   |
+-------+-----------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
| x     | CREATE TABLE `x` (
  `q` int(11) NOT NULL auto_increment,
  `w` int(11) default NULL,
  PRIMARY KEY  (`q`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 |
+-------+-----------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> show create table y;
+-------+-----------------------------------------------------------------------
                                             --------------------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                                                                                                                                                                                |
+-------+-----------------------------------------------------------------------
                                             --------------------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
| y     | CREATE TABLE `y` (
  `a` int(11) NOT NULL,
  `s` int(11) default NULL,
  KEY `a` (`a`),
  CONSTRAINT `y_ibfk_1` FOREIGN KEY (`a`) REFERENCES `x` (`q`) ON DELETE CASCADE                                              ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=cp1251 |
+-------+-----------------------------------------------------------------------
                                             --------------------------------------------------------------------------------
                                             ----------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> select * from x;
+---+------+
| q | w    |
+---+------+
| 1 |    1 |
| 2 |    2 |
+---+------+
2 rows in set (0.00 sec)

mysql> select * from y;
+---+------+
| a | s    |
+---+------+
| 1 |    1 |
| 2 |    1 |
| 3 |    1 |
+---+------+
3 rows in set (0.00 sec)

anonymous
()
Ответ на: комментарий от anonymous

Гм...

$ mysql -V
mysql Ver 14.12 Distrib 5.0.26, for pc-linux-gnu (i686) using readline 5.1

anonymous
()
Ответ на: комментарий от anonymous

В MySQL можно отключать проверку для соединения при помощи SET FOREIGN_KEY_CHECKS=0 (ну и включать соответственно SET FOREIGN_KEY_CHECKS=1). Если проверка отключена то вы можете добавлять какие угодно данные, но это на вашей совести ;)

anonymous
()
Ответ на: комментарий от r

> а ты foreign key делал во время создания или alter table (если конечно мускуль такое умеет)?

Во время создания.
Я это заметил получилось после чистки дампа и заливки оного обратно. Чистилась таблица с PK. Насколько я понимаю, такой результат можно получить выключеним перед чисткой проверок ключей (и включением их потом).
Но какая разница ? Если FK висит - од обязан выполняться. Либо его не должно быть. В PG вы такого не увидите. Там либо есть FK и все его значения имеют место быть в таблице с PK, либо нет FK вообще. Фокус с чисткой дампа не проходит :)

anonymous
()
Ответ на: комментарий от anonymous

> В MySQL можно отключать проверку для соединения при помощи SET FOREIGN_KEY_CHECKS=0 (ну и включать соответственно SET FOREIGN_KEY_CHECKS=1). Если проверка отключена то вы можете добавлять какие угодно данные, но это на вашей совести ;)

Не вопрос. Почему она не срабатывает после включения ? Ведь при создании ограничения проверяется же наличие всех значений ключа.

anonymous
()
Ответ на: комментарий от anonymous

> Не вопрос. Почему она не срабатывает после включения ? Ведь при создании ограничения проверяется же наличие всех значений ключа.

Она и не должна срабатывать при включении. Точнее после ее включения у вас будут проверяться все вновь добавляемые данные, но те данные которые _уже_ в таблице проверяться не будут. О чем и написано в документации. Подразумевается что вы знаете зачем отключаете.

anonymous
()
Ответ на: комментарий от anonymous

>В PG вы такого не увидите.

Ну дык. Вот причина в числе которых почему я с мускулем не работаю, а работаю с посгресом.

r ★★★★★
()
Ответ на: комментарий от anonymous

>Подразумевается что вы знаете зачем отключаете.

Например для рестора базы? Иначе никак.

Чел прав - посгрес вам таких греблей не даст - попытка навесить констрейнт на таблицу в которой есть нарушение ключа вызовет приблизительно вот такое:

ERROR: insert or update on table "tb" violates foreign key constraint "fk_ta" ПОДРОБНО: Ключ (fk)=(3) отсутствует в таблице "ta".

К стати а deferred constraints есть в mysql?

r ★★★★★
()
Ответ на: комментарий от anonymous

> Точнее после ее включения у вас будут проверяться все вновь добавляемые данные, но те данные которые _уже_ в таблице проверяться не будут. О чем и написано в документации

Я ж и говорю - целостность данных по ключам до ума так и не довели. Как говорится, не можете исправить баг - назовите его фичей :)

anonymous
()
Ответ на: комментарий от r

> Чел прав - посгрес вам таких греблей не даст - попытка навесить констрейнт на таблицу в которой есть нарушение ключа вызовет приблизительно вот такое:

В мускуле будет то же самое для движка InnoDB. Отличие в том, что мускул отключает проверки при восстановлении дампа. Если дамп правленный, то можно получить такую ситуацию. В PG дампер работает по другому. Он сначала создает все таблицы и запихивает в них все данные, а потом начинает навешивать индексы, ограничение и прочее. Таким образом, либо целостность сохранится, либо будет отсутствовать ограничение, о чем будет сообщено в ошибке.

anonymous
()
Ответ на: комментарий от anonymous

>Таким образом, либо целостность сохранится, либо будет отсутствовать ограничение, о чем будет сообщено в ошибке.

Не так. Посгрес не даст вам создать базу в которой разрушена referential integrity. Вы либо не сможете наложить ограничения на сопротивляющиеся данные, либо ввести данные, которым сопротивляются ограничения - в любом случае надо что-то будет фиксить. А не получить ситуацию "все настроено, но ничего не работает".

Я не просто так спросил про deferred constraints. Я к стати посмотрел - не умеет мускуль такого (я сразу так и заподозрил когда увидел что констрейнты выключаются переменной). Если бы мускуль умел, то механизм проверки deferred constraint и чека таблицы на соответствие новому налогаемому constraint был бы аналогичен. В этом и вся причина - они пока такого не асилели (к стати в доке на mysql по FK прям так и написано - что это все эти "фичи" пока они не асилели deferred constraints, а потом они станут багами).

r ★★★★★
()
Ответ на: комментарий от r

> Не так. Посгрес не даст вам создать базу в которой разрушена referential integrity. Вы либо не сможете наложить ограничения на сопротивляющиеся данные, либо ввести данные, которым сопротивляются ограничения

Ну так... А я что сказал в цитируемом тексте ? :)

> в любом случае надо что-то будет фиксить.

Это да. В случае с постгресом я хоть буду об этом знать :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.