Настройка типа выборки в hyperjaxb

Question

Я прочитал this link о fetchtype в hyperjaxb. По внешнему виду кажется, что можно добавить simpleTypefetch-type в файл xsd, а затем добавить fetch атрибут для каждого complexType.

Как можно настроить следующий фрагмент xsd так, чтобы полученный java-метод внизу внизу имел аннотацию fetchtype=lazy?

<xs:complexType name="SomeTypeName"> 
    <xs:sequence> 
     <xs:element name="title" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> 
     <xs:element name="someCode1" type="Code" minOccurs="0"/> 
     <xs:element name="someCode2" type="Code" minOccurs="0"/> 
     <xs:element name="someCode3" type="Code" minOccurs="0"/> 
     <xs:element name="someCode4" type="Code" minOccurs="0"/> 
     <xs:element name="someCode5" type="Code" minOccurs="0"/> 
    </xs:sequence> 
</xs:complexType> 

<xs:complexType name="Code"> 
    <!--<xs:sequence>elements with nested data types omitted for simplicity</xs:sequence>--> 
    <xs:attribute name="code" type="xs:string" use="optional"></xs:attribute> 
    <xs:attribute name="Name" type="xs:string" use="optional"></xs:attribute> 
</xs:complexType> 

Вот свойство Java, который должен сказать, fetchtype = ленивое:

@ManyToOne(targetEntity = Code.class, cascade = { 
    CascadeType.ALL 
}) 
@JoinColumn(name = "SOME_CODE1_P_0") 
public Code getSomeCode1() { 
    return someCode1; 
} 

Кроме того, как конкретно (то есть с тем, что конкретный синтаксисом) делает один набор глобальным по умолчанию для fetchtype во всех методах, так что только некоторые свойства должны быть переопределены?

Answer 1

Пожалуйста, смотрите подобный вопрос на примере на cascade ранее спросил:

customizing hibernate properties in hyperjaxb

И проверить Hyperjaxb customizations schema, который использует JPA ORM schema:

• many-to-one/@fetch
• fetchType

Это приведет к что-то вроде:

<jaxb:bindings schemaLocation="schema.xsd" node="/xs:schema"> 
    <hj:persistence> 
     <hj:default-many-to-one fetch="LAZY"> 
      <!-- ... --> 
     </hj:default-many-to-one> 
    </hj:persistence> 
</jaxb:bindings> 

Если вы хотите fetch="LAZY" на все ваши ассоциации, вам придется настроить default-one-to-one, default-one-to-many, default-many-to-many, а также. Эти настройки будут применяться глобально (семантика «сопоставлений по умолчанию»). Вам не нужно настраивать сотни свойств.

Hyperjaxb на самом деле имеет три уровня отображения:

• Built-in defaults - встроенные отображения по умолчанию. Это внутренние значения Hyperjaxb
• Customized default mappings - по умолчанию вы можете настроить для каждой схемы. Поэтому, если по какой-то причине вас не устраивают по умолчанию, вы можете предоставить свои собственные сопоставления по умолчанию - только там, где вы хотите их разных из встроенных значений по умолчанию.
• Customized property and association mappings или classes - вещи, которые вы настраиваете для определенного класса, имущества или ассоциации. Опять же, только там, где вы хотите, чтобы они отличались от настроенных или встроенных значений по умолчанию.

Эти уровни настроек наследуются друг от друга. Поэтому, если вы не настроите, вы получите встроенные значения по умолчанию.

---

Касательно вашей обратной связи по качеству документации Hyperjaxb. Я абсолютно согласен с тем, что он очень далек от того, чтобы быть оптимальным (на самом деле это не оспаривалось).

Но это лучшее состояние, которое возможно на данный момент. У меня просто нет ресурсов для активного развития или продвижения проекта. Hyperjaxb - это нишевый инструмент, который предлагает очень ограниченное количество проектов или приложений. Существует некоторый, но очень низкий интерес пользователей/разработчиков, что экономически нецелесообразно разрабатывать и поддерживать полный или даже неполный рабочий день.

Проще говоря, мои варианты на данный момент являются:

• закрыть и отказаться от проекта
• оставить его на поддержание низкого пламени

Я бы закрыть и оставить проект давно, но:

• Я знаю, что есть пользователи, которые довольны Hyperjaxb, как есть.
• Я не знаю никакого аналога Hyperjaxb, который обеспечил бы - даже отдаленно - ту же функциональность и мощность. Под «аналоговым» я подразумеваю все, что создавало бы классы с поддержкой JPA на основе XML-схемы. Конечно, есть и другие инструменты, такие как блестящие MOXy, которые используют другие источники (классы Java, UML, что угодно), но я не знаю другого инструмента, который бы делал XSD-> Java + JPA. К сожалению, похоже, что я разработал уникальный инструмент.

Так что в этой ситуации я могу оставить проект на очень низком огне, просто фиксируя серьезные ошибки и проблемы. Поскольку документация настолько хороша, насколько это определенно, она повышает привлекательность и необходимый опыт для изучения инструмента. Я бы сказал, что для этого есть все средства: есть более 50 + страниц документации, готовых к запуску учебников и образцов, «просто добавьте воду» в проекты шаблонов, доступно более 60 тестовых проектов. Но он уверен, что поднимает трезубство.

И я искренне сожалею, что это не сработает для вас. Примите мои извинения за невыполнение ваших ожиданий.

Отзывы «Ваша документация плохая», независимо от того, насколько она верна, не является полезным вкладом. Спасибо за эту обратную связь, но нет, у меня нет ресурсов, чтобы усердно работать, чтобы упростить использование Hyperjaxb.

Полезный вклад будет:

• отчетности bugs and issues так, чтобы они могли быть воспроизведены и фиксированы.
• Предоставление pull requests, чтобы я мог рассмотреть и объединить их.
• Помощь с documentation.