Быстрый NHibernate и migratordotnet играют приятно вместе?
Я тоже застрял на этом. Для записи вы должны быть в классе, который Xcode распознает как содержащий тесты. Добавьте файл в свою цель тестирования пользовательского интерфейса с помощью чего-то вроде:
import Foundation
import XCTest
class MyTests: XCTestCase {
func testSomething() {
}
}
Сохраните файл, очистите ваш проект и переключитесь на другой файл, а затем вернитесь к этому. Кнопка записи должна быть доступна.
4 ответа
Гордон,
У меня был тот же вопрос по предыдущим проектам, и мы решили использовать migratordotnet исключительно для миграции наших баз данных и просто вообще пропустили SchemaUpdate.
Я по-прежнему буду использовать SchemaUpdate для быстрых прототипов, но как только я начну всерьез проект, я буду использовать только migratordotnet.
При настройке миграции для запуска в рамках наших ночных сборок migratordotnet работает очень хорошо, если над проектом работает более одного человека.
Я также сталкиваюсь с той же проблемой, когда мне не нужно поддерживать миграции (используя migratordotnet) и мои файлы сопоставления независимо друг от друга. Единственное, что я нашел до сих пор, - это SchemaUpdate NHibernate, но он не обрабатывает удаление столбцов или таблиц. Для этих типов изменений вам все равно придется вручную написать миграцию. Прямо сейчас я склоняюсь к использованию migratordotnet исключительно для изменений базы данных вместо смешивания SchemaUpdate, генерирующего DDL и миграции. Тем не менее, это по-прежнему кажется подверженным ошибкам, так как вы могли неправильно преобразовать изменения уровня сопоставления / домена в миграции.
У меня такая же проблема. Вот мой текущий рабочий процесс, который позволяет избежать SchemaUpdate:
- создать базу данных с нуля (если были внесены какие-либо изменения)
- сохранить все справочные данные в электронных таблицах
- перезагрузить все данные через специальную командную строку проекта 'dataloader'
Этот рабочий процесс хорошо подходит для разработки, так как восстановление и заполнение базы данных с нуля каждый раз решает проблему контроля версий базы данных. Это также обеспечивает хорошую основу для тестирования вашей БД и фактических данных, которые вы вставляете.
Очевидно, что это не будет работать в производственной среде, когда работает живая база данных, которую нельзя отбросить и перестроить волей-неволей. Вот что я делаю:
- После завершения цикла разработки я беру клон производственной базы данных. База данных Prod сделана только для чтения на время обновления (хорошо для моего приложения ... не уверен насчет большего количества критичных по времени приложений)
- Используйте SQL Compare для переноса изменений и данных из разработчика в базу данных prod
- отправьте это для тестирования.
- Если тест пройден, нажмите на продакшн.
Это не идеально и использует коммерческий продукт SQL Compare. Это работает для меня, но я хотел бы услышать несколько лучших идей.
Да, в основном. Я успешно использую как FNH, так и migratordotnet для толстого настольного клиента, и он работает довольно хорошо. Мне пришлось модифицировать его по двум причинам:
чтобы разрешить внедрение sql-соединения в TransformationProvider (или, точнее, в SQLiteTransformationProvider)
вырвать ссылки на другие не sqlite TransformationProviders, как когда я пытался упаковать это с моим приложением, оно выдавало бы различные ошибки о невозможности найти Oracle, Postgres и т. д.
Это специфично для sqlite — взломайте его, чтобы лучше анализировать операторы sqlite create table. К сожалению, он не может обрабатывать операторы создания таблицы в форме
CREATE TABLE FOO(id INT, ..., primary key(id))(в отличие отCREATE TABLE FOO(id INT PRIMARY KEY , ...), который он обрабатывает). Объедините это с тем, как он выполняет удаление столбцов (создайте новую таблицу без столбца, перенесите данные, удалите исходный и переименуйте новый в исходный), это означает, что вы можете получить довольно неприятное поведение, такое как удаление столбца в таблице, превращающее ваш столбец первичного ключа в столбец, не являющийся первичным ключом.