В новинку для Муравья - проблема с относительными путями
"Они могут сделать записи удаления более громоздкими - Вы не можете удалить "основную" запись, где существуют записи в других таблицах, где внешние ключи нарушили бы то ограничение".
важно помнить, что стандарт SQL определяет меры, которые приняты, когда внешний ключ удален или обновлен. Те, о которых я знаю:
-
ON DELETE RESTRICT- Предотвращает любые строки в другой таблице, которые имеют ключи в этом столбце от того, чтобы быть удаленным. Это - то, что Ken Ray описал выше. -
ON DELETE CASCADE- Если строка в другой таблице удалена, удалите любые строки в этой таблице, которые ссылаются на него. -
ON DELETE SET DEFAULT- Если строка в другой таблице удалена, устанавливает любые внешние ключи, ссылающиеся на него к значению по умолчанию столбца. -
ON DELETE SET NULL- Если строка в другой таблице удалена, устанавливает любые внешние ключи, ссылающиеся на него в этой таблице к пустому указателю. -
ON DELETE NO ACTION- Этот внешний ключ только отмечает это, это - внешний ключ; а именно, для использования в ИЛИ картопостроителей.
Эти те же действия также относятся ON UPDATE.
значение по умолчанию, кажется, зависит, на котором сервер sql Вы используете.
1 ответ
Весь путь Ant будет относиться к вашему текущему рабочему каталогу.
Итак, проверьте, из какого каталога вы запускаете свой скрипт.
Я предлагаю вам начать использовать $ {basedir} , чтобы получить путь относительно местоположения build.xml .
В вашем случае относительный путь должен быть построен следующим образом: $ {basedir } /../../ core вместо ../../ core .
Несоответствия, с которыми вы сталкиваетесь, иллюстрируют то, почему сгенерированные eclipse скрипты муравьев являются хорошей отправной точкой , но никогда не бывает хорошей системой сборки проекта.
EDIT . Интересно, почему генератор муравьев eclipse не вставляет $ {basedir} в относительные пути? Возможно, вам стоит сообщить об этом как об ошибке.