Базите данни позволяват лоши външни ключове от Rails Fixtures

Използвам Rails Fixtures, за да заредя някои тестови данни в моята база данни и случайно въведох външен ключ извън обхвата.

За моя изненада базата данни го прие, въпреки че има ограничения за референтна цялост (които работят). Опитах с PostgreSQL и с MySQL InnoDB и двете бяха разрешени.

Пример:

В базата данни "Вкусове" с цифров първичен ключ (id), 5 записа (1 до 5). Мога да представя лоши данни:

Icecream_1: име: моят вкус на сладолед_id: 6

Как е възможно зареждането на приспособленията да заобикаля ограниченията на моята база данни?

Благодаря ти.


Ето две таблици. Имайки 200 user_types (фалшиви данни), успях да въведа потребител с user_type_id 201, но само от приспособления, pgAdmin го забранява.

CREATE SEQUENCE user_types_id_seq;
CREATE TABLE user_types (
id SMALLINT
  NOT NULL
  DEFAULT NEXTVAL('user_types_id_seq'),
name VARCHAR(45) 
  NOT NULL 
  UNIQUE,
PRIMARY KEY (id));

CREATE SEQUENCE users_id_seq;
CREATE TABLE users (
id BIGINT
    NOT NULL
    DEFAULT NEXTVAL('users_id_seq'),
user_type_id SMALLINT
    NOT NULL
    REFERENCES user_types (id) ON DELETE CASCADE ON UPDATE CASCADE,
PRIMARY KEY (id));


---------

Fixture

<% for i in (1..201) %>

user_<%= i %>:
    id: <%= i %>
    user_type_id: <%= i %>
<% end %>

И както казах, както innoDb, така и postgresql приеха лошия ключ.

Благодаря


person Ferreira    schedule 13.08.2010    source източник
comment
Можем ли да разгледаме дефинициите на вашите таблици? Може да има следа там.   -  person Brian Hooper    schedule 13.08.2010


Отговори (4)


PostgreSQL не приема повредени данни, не се притеснявайте. В MySQL всичко зависи от двигателя (трябва да е innoDB) и настройките (връзка) за параметъра Foreign_key_checks.

Как изглеждат вашите таблици и ограничения? Проверете pgAdmin (или някой друг клиент) и изхвърлете съответната част от модела на данни тук, тогава можем да ви помогнем.

pgAdmin го забранява.

Не, вашата база данни PostgreSQL го забранява. pgAdmin е просто клиент и само изпраща заявка към базата данни. Базата данни прави някои проверки, FK е нарушен и връща грешка.

Изглежда, че работите върху грешна база данни (без FK или MySQL с грешен двигател и/или настройки), PostgreSQL работи добре, когато имате FK.

person Frank Heikens    schedule 13.08.2010

Съгласен съм с Франк. Вашата тестова база данни за PostgreSQL най-вероятно не е настроена правилно. Или сте забравили да създадете FK ограниченията, или сте ги деактивирали.

Фактът, че сте получили грешка в pgAdmin, показва, че работите с различна база данни от pgAdmin и вашия тестов скрипт.

Що се отнася до MySQL, бих потърсил грешен двигател по подразбиране в тестовата база данни или ако също сте забравили да създадете FK ограниченията там (имайте предвид, че няма да получите грешка, ако създадете FK ограничение с двигател, който не не поддържа референтна цялост на MySQL)

person a_horse_with_no_name    schedule 13.08.2010

Проверете дефинициите на таблиците във вашата тестова база данни. IIRC, "rake db:test:prepare" не поддържа вярност при създаване на таблиците в тестовата база данни.

person nirvdrum    schedule 13.08.2010

Благодаря на всички за отговора.

Някой от ruby ​​forum го разбра. Изглежда, че тригерите, които налагат RI, са деактивирани преди зареждането на приспособленията.

Не знам защо, но разгадава мистерията.

person Ferreira    schedule 13.08.2010
comment
Тези тригери не са тригерите на базата данни, невъзможно е в PostgreSQL да деактивирате ограниченията на външния ключ (известни още като тригери). Вашата база данни има FK или няма FK, няма нещо като деактивиран FK. - person Frank Heikens; 13.08.2010
comment
Мисля, че ще откриете, че таблиците в MySQL, които налагат референтна цялост, трябва да бъдат създадени с клаузата ENGINE=INNODB. Ако не са, те може да съхраняват ограниченията, но не действат спрямо тях. - person Brian Hooper; 13.08.2010
comment
Да, Брайън, прав си, всички таблици в MySQL имат ENGINE=INNODB. - person Ferreira; 13.08.2010
comment
Франк, това също си мислех и причината да публикувам този въпрос. Предполага се, че приспособленията извършват много операции с DB, включително изтриване/прочистване и предполагам, че трябва да обикалят RI, за да го направят. - person Ferreira; 13.08.2010
comment
Всъщност можете да деактивирате системните тригери, които изпълняват FK проверките, но само като суперпотребител (ALTER TABLE foo DISABLE TRIGGER ALL) Най-вероятно тестовата програма прави това. Друг добър пример защо разработката не трябва да се извършва с помощта на суперпотребител на база данни... - person a_horse_with_no_name; 13.08.2010
comment
Ако тестовото зареждане деактивира ограниченията, това е опасно. Това е напълно неуместно. - person matthudson; 22.05.2013