Что лучший способ состоит в том, чтобы инициализировать боб?
Вам не нужно удалять и воссоздавать внешние ключи. Вместо этого используйте отложенные ограничения. Этого достаточно, когда вы определяете внешние ключи как deferrable initially deferred и выполняете все вставки в одной транзакции. Однако есть больше вариантов, поэтому читайте об отложенных ограничениях в документации:
Использовать системный каталог pg_constraint.
Вы можете сгенерировать скрипт для изменения внешних ключей на DEFERRABLE INITIALLY DEFERRED следующим образом:
select format(
'ALTER TABLE %s ALTER CONSTRAINT %s DEFERRABLE INITIALLY DEFERRED;',
conrelid::regclass::text,
conname)
from pg_constraint
where contype = 'f'
and conrelid = any(array['table1', 'table2', 'table3']::regclass[])
and connamespace = 'ssp2_pcat'::regnamespace;
Вы можете запустить скрипт один раз. Тогда ваш скрипт импорта может выглядеть так:
BEGIN;
TRUNCATE table1;
TRUNCATE table2;
...
INSERT INTO table1...
INSERT INTO table2...
...
COMMIT;
Если по какой-то причине вы не можете использовать отложенные ограничения, используйте сценарий для удаления ограничений:
select
format(
'ALTER TABLE %s DROP CONSTRAINT %s;',
conrelid::regclass::text,
conname)
from pg_constraint
where contype = 'f'
and conrelid = any(array['table1', 'table2', 'table3']::regclass[])
and connamespace = 'ssp2_pcat'::regnamespace;
и для воссоздания их:
select
format(
'ALTER TABLE %s ADD CONSTRAINT %s %s;',
conrelid::regclass::text,
conname,
pg_get_constraintdef(oid))
from pg_constraint
where contype = 'f'
and conrelid = any(array['table1', 'table2', 'table3']::regclass[])
and connamespace = 'ssp2_pcat'::regnamespace;
5 ответов
Я не уверен, что существует "лучший" способ инициализировать боб. Я думаю, что существуют за и против каждому, и в зависимости от ситуации, один или другой могло бы быть соответствующим. Это, конечно, не исчерпывающий список, но здесь является некоторыми вещами рассмотреть.
Используя конструктора позволяет Вам иметь неизменный боб. Неизменные объекты хороши, если можно приспособить их в дизайне. Они не требуют копирования, сериализированного доступа или другой специальной обработки между потоками. Если у Вас есть методы set, Ваш объект не неизменен. Используя конструктора также гарантирует, что объект правильно инициализируется. После того, как конструктор заканчивает, объект доступен. Если Ваш объект требует, чтобы использование методов set инициализировало его, возможно иметь недопустимый объект.
С другой стороны, использование конструкторов часто приводит к складывающейся проблеме. Часто времена, Вам будут нужны многие различные конструкторы, большинство которых будет надмножеством другого конструктора. Часто времена это для удобства. Например:
public class Person {
public Person(String name) { ... }
public Person(String name, String phone) { ... }
public Person(String name, String phone, String email) { ... }
}
Одна альтернатива этому, что мне очень нравится, является так называемым "расширенным" шаблоном разработчика, представленным Josh Bloch в JavaOne. Вы видите это в его книге "Эффективный Java, Второй Выпуск". При рассмотрении способа, которым используется шаблон, он также решит "afterProperties" проблему метода. Шаблон разработчика гарантирует, что объект правильно инициализируется.
Вот дополнительное сообщение в блоге, обсуждая шаблон: http://www.screaming-penguin.com/node/7598
Я не уверен, что это вписывается в Ваше пружинное требование, но в целом, я - большой поклонник разработчика.
IMO, которым главное преимущество инжекции конструктора состоит в том, что это совместимо с неизменностью. Однако, если класс имеет больше, чем приблизительно 3 зависимости, это требует обеспечения конструктора, который берет большое количество параметров, которое является громоздким.
При использовании инжекции метода set я предпочитаю использовать @PostConstruct аннотация для идентификации метода инициализации. Это включает более свободную связь с платформой Spring, чем afterProperties() метод, который Вы упоминаете (на самом деле, я думаю, что это afterPropertiesSet()). Другая опция является init атрибутом метода <bean> элемент.
Я не знаю версии, которую Вы в настоящее время используете, но если это - Spring 2.5, Вы могли бы также рассмотреть использование @Autowired аннотации для определенных случаев. Это крупных только работает на ссылки на другие бобы а не на Строки и т.д. как в примере lycony.
Это сохраняет Вас нагрузка создания методов set и/или конструкторов и большого количества конфигурации. Немного Примера:
public class MyPersonBean {
@Autowired
private PersonManager personManager;
public void doSomething() {
this.personManager.doSomething();
}
}
И в Вашем файле конфигурации:
<context:annotation-config/>
Автопроводное соединение сделано типом, поэтому если у Вас будет боб типа PersonManager, то это введет его в аннотируемом поле. В случае, если у Вас есть больше бобов того типа, можно использовать @Qualifier аннотацию, чтобы сказать им независимо...
Можно найти больше информации об автопроводном соединении в Справочной документации Spring
Я начал использовать @Autowired в сочетании со сканированием компонента в моем предыдущем проекте, и я должен сказать, что избавился больше чем от 90% своих конфигурационных файлов Spring.
Компромиссы:
Конструктор: Преимущества: Может быть очень простым, особенно с тремя или меньше свойствами для инициализации. Одноразовый, нет/минимальный дополнительная конфигурация для волнения о.
Недостатки: Несколько конструкторов должны быть созданы для нескольких Конструкторов ситуаций, не наследованы, таким образом, классы должны звонить супер () и обеспечить дублирующихся конструкторов для разрешения предыдущего поведения.
Методы set: Преимущества: Дети наследовали методы set, таким образом, свойства могут быть легко переопределены для влияния на поведение после конструкции. Несколько свойств могут быть указаны объединенным способом, не ища различные сигнатуры методов (конвенции JavaBeans)
Недостатки: Каждый метод set должен быть вызван явно для каждого свойства. Приводит к некоторым классам, имеющим большие количества свойств явно набор.
Можно также использовать @Resource автосоединять проводом вместо @Autowired, это работает отчасти как автопроводное прозвище, таким образом, Вы не должны волноваться, существует ли больше бобов с тем же типом (отдел, можно также обработать это с @Qualifier, но я только рекомендовал бы что описать характеристику боба). Это действительно зависит от Вашего варианта использования, какой способ будет лучшим, таким образом, необходимо будет оценить его для ситуации и решить после.