Быть в спящем режиме по сравнению с JPA по сравнению с JDO - за и против каждого? [закрытый]
Большое спасибо Стив, Майк, Алекс. Я согласился с решением Стива (см. Код ниже). Моя единственная оставшаяся проблема заключается в том, что график контура появляется за моими линиями сетки, в отличие от обычного сюжета, который я могу заставить фронт с zorder.
Приветствия, Геддес
import matplotlib.pyplot as plt
from matplotlib.ticker import MultipleLocator, FormatStrFormatter
import numpy as np
fig = plt.figure(1)
ax = fig.add_subplot(111)
# set up axis
ax.spines['left'].set_position('zero')
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
# setup x and y ranges and precision
x = np.arange(-0.5,5.5,0.01)
y = np.arange(-0.5,5.5,0.01)
# draw a curve
line, = ax.plot(x, x**2,zorder=100)
# draw a contour
X,Y=np.meshgrid(x,y)
F=X**Y
G=Y**X
ax.contour(X,Y,(F-G),[0],zorder=100)
#set bounds
ax.set_xbound(-1,7)
ax.set_ybound(-1,7)
#produce gridlines of different colors/widths
ax.xaxis.set_minor_locator(MultipleLocator(0.2))
ax.yaxis.set_minor_locator(MultipleLocator(0.2))
ax.xaxis.grid(True,'minor',linestyle='-')
ax.yaxis.grid(True,'minor',linestyle='-')
minor_grid_lines = [tick.gridline for tick in ax.xaxis.get_minor_ticks()]
for idx,loc in enumerate(ax.xaxis.get_minorticklocs()):
if loc % 2.0 == 0:
minor_grid_lines[idx].set_color('0.3')
minor_grid_lines[idx].set_linewidth(2)
elif loc % 1.0 == 0:
minor_grid_lines[idx].set_c('0.5')
minor_grid_lines[idx].set_linewidth(1)
else:
minor_grid_lines[idx].set_c('0.7')
minor_grid_lines[idx].set_linewidth(1)
minor_grid_lines = [tick.gridline for tick in ax.yaxis.get_minor_ticks()]
for idx,loc in enumerate(ax.yaxis.get_minorticklocs()):
if loc % 2.0 == 0:
minor_grid_lines[idx].set_color('0.3')
minor_grid_lines[idx].set_linewidth(2)
elif loc % 1.0 == 0:
minor_grid_lines[idx].set_c('0.5')
minor_grid_lines[idx].set_linewidth(1)
else:
minor_grid_lines[idx].set_c('0.7')
minor_grid_lines[idx].set_linewidth(1)
plt.show()
9 ответов
Некоторые примечания:
- JDO и JPA являются оба спецификациями, не реализациями.
- идея - Вы, может подкачать реализации JPA, если Вы ограничиваете свой код для использования стандартного JPA только. (Так же для JDO.)
- В спящем режиме, может использоваться в качестве одной такой реализации JPA.
- Однако В спящем режиме, обеспечивает встроенный API, с функциями выше и кроме того JPA.
IMO, которые я рекомендовал бы, в спящем режиме.
<час>были некоторые комментарии / вопросы о том, что необходимо сделать, если Вы потребность для использования В спящем режиме - определенные функции. Существует много способов посмотреть на это, но мой совет был бы:
-
, Если Вы не волнуетесь перспективой принудительного ассортимента поставщика, затем сделайте свой выбор между, в спящем режиме, и другой JPA и реализации JDO включая различный поставщик определенные расширения в Вашем принятии решений.
-
, Если Вы волнуетесь перспективой принудительного ассортимента поставщика, и Вы не можете использовать JPA, не обращаясь к поставщику определенные расширения, затем не используйте JPA. (Так же для JDO).
В действительности, Вам, вероятно, будет нужно к компромиссу , насколько Вы волнуетесь принудительным ассортиментом поставщика по сравнению с , насколько Вам нужны они поставщик определенные расширения.
И существуют другие факторы также, как то, как хорошо Вы / Ваши сотрудники знают соответствующие технологии, какого количества продукты будут стоить в лицензировании, и чьей истории Вы верите о том, что собирается произойти в будущем для JDO и JPA.
JDO мертв
, JDO не мертв на самом деле, поэтому проверьте свои факты. JDO 2.2 был выпущен, в октябре 2008 JDO 2.3 разрабатывается.
Это разрабатывается открыто под Apache. Больше выпусков, чем JPA имело, и его спецификация ORM все еще даже перед предложенными функциями JPA2
, Который Вы предложили бы для нового проекта?
я не предложил бы ни одного! Примените ДАО Spring JdbcTemplate вместе с StoredProcedure, RowMapper и RowCallbackHandler вместо этого.
Мой собственный личный опыт с В спящем режиме, то, что время сохранило, заранее больше, чем смещается бесконечными днями, Вы потратите по линии попытку понять и отладить проблемы как неожиданное поведение каскадного обновления.
, Если Вы используете реляционный DB затем, чем ближе Ваш код к нему, тем больше контроля Вы имеете. Уровень DAO Spring позволяет точную регулировку отображающегося слоя при устранении необходимости шаблонного кода. Кроме того, это интегрируется на слой транзакции Spring, что означает, что можно очень легко добавить (через AOP), усложнил транзакционное поведение без этого внедрения в код (конечно, Вы добираетесь, это с В спящем режиме также).
Я изучал это сам и не могу найти сильное различие между двумя. Я думаю, что большой выбор находится, в которой реализации Вы используете. Для меня я рассматривал платформа DataNucleus , поскольку это - реализация агностика хранилища данных обоих.
Я использую JPA (реализацию OpenJPA от Apache, которая основана на кодовой базе KODO JDO, которой более 5 лет, и очень быстро / надежно). ИМХО любой, кто говорит вам обойти спецификации, дает вам плохой совет. Я положил время и определенно был вознагражден. Используя JDO или JPA, вы можете менять поставщиков с минимальными изменениями (в JPA есть сопоставление форм, поэтому мы говорим о том, чтобы поменять поставщиков менее чем за один день). Если у вас есть более 100 столов, как у меня, это огромно. Кроме того, вы получаете встроенное кеширование с удалением кеша по кластеру и все это хорошо. SQL / Jdbc отлично подходит для высокопроизводительных запросов, но прозрачное постоянство намного лучше для написания ваших алгоритмов и процедур ввода данных. У меня всего около 16 запросов SQL во всей моей системе (50 000+ строк кода).
JDO имеет расширенные функции, чем JPA, см. http://db.apache.org/jdo/jdo_v_jpa.html
Я использовал Hibernate (реализация JPA) и JPOX (реализация JDO) в одном проекте. JPOX работал нормально, но довольно быстро обнаруживал ошибки там, где некоторые функции языка Java 5 не поддерживались в то время. У него были проблемы с обработкой транзакций XA. Я создавал схему базы данных из объектов JDO. Он хотел подключаться к базе данных каждый раз, что раздражает, если ваше соединение с Oracle не работает.
Затем мы перешли на спящий режим. Некоторое время мы играли с простым использованием JPA, но нам нужно было использовать некоторые специфические функции Hibernate для сопоставления. Выполнить один и тот же код в нескольких базах данных очень просто. Кажется, что Hibernate агрессивно кэширует объекты или временами просто ведет себя странно. Существует несколько конструкций DDL, которые Hibernate не может обрабатывать, поэтому они определены в дополнительном файле, который запускается для инициализации базы данных. Когда я сталкиваюсь с проблемой Hibernate, часто многие люди сталкиваются с той же проблемой, что упрощает поиск решений в Google. Наконец, Hibernate кажется хорошо продуманным и надежным.
Некоторые другие респонденты предложили просто использовать SQL. Настоящий убийственный вариант использования объектно-реляционного сопоставления - это тестирование и разработка. Базы данных, созданные для обработки больших объемов данных, обычно дороги или их сложно установить. С ними сложно тестировать. Существует множество баз данных Java в памяти, которые можно использовать для тестирования, но обычно они бесполезны для производства.Возможность использовать реальную, но ограниченную базу данных повысит продуктивность разработки и надежность кода.
Убедитесь, что вы оценили реализацию JDO в DataNucleus. Мы начали с Hibernate, потому что он казался очень популярным, но довольно скоро поняли, что это не 100% прозрачное решение для сохранения.Слишком много предостережений, и документация полна слов «если у вас возникла такая ситуация, вы должны написать свой код вот так», что лишило нас удовольствия от свободного моделирования и кодирования, как мы того хотим. JDO никогда не заставлял меня корректировать мой код или мою модель, чтобы заставить их «работать должным образом». Я могу просто проектировать и кодировать простые POJO, как если бы я собирался использовать их только «в памяти», но я могу сохранять их прозрачно.
Другое преимущество JDO / DataNucleus перед спящим режимом заключается в том, что он не требует всех накладных расходов на отражение во время выполнения и более эффективен с точки зрения памяти, поскольку использует улучшение байтового кода времени сборки (возможно, добавьте 1 секунду к времени сборки для большого project), а не шаблон прокси с отражением во время выполнения hibernate.
Еще одна вещь, которая может вас раздражать в Hibernate, - это то, что у вас есть ссылка на то, что вы считаете объектом ... часто это «прокси» для объекта. Без преимущества улучшения байт-кода требуется шаблон прокси, чтобы разрешить загрузку по требованию (т. Е. Избежать затягивания всего графа вашего объекта, когда вы втягиваете объект верхнего уровня). Будьте готовы переопределить equals и hashcode, потому что объект, на который вы думаете, что ссылаетесь, часто является просто прокси для этого объекта.
Вот пример разочарований, которые вы получите с Hibernate, чего не получите с JDO:
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe- equals.html
http://burtbeckwith.com/blog/?p=53
Если вам нравится кодировать «обходные пути», то, конечно, Hibernate для вас.Если вы цените чистую, объектно-ориентированную разработку на основе моделей, при которой вы тратите все свое время на моделирование, проектирование и кодирование, а не на уродливые обходные пути, тогда потратьте несколько часов на оценку JDO / DataNucleus . Вложенные часы окупятся в тысячу раз.
Обновление, февраль 2017 г.
В течение некоторого времени DataNucleus реализует стандарт сохраняемости JPA в дополнение к стандарту сохраняемости JDO, поэтому перенос существующих проектов JPA из Hibernate в DataNucleus должен быть очень простым, и вы можете получить все вышеперечисленное. упомянутые преимущества DataNucleus с очень небольшим изменением кода, если таковые имеются. Итак, с точки зрения вопроса, выбор конкретного стандарта, JPA (только РСУБД) против JDO (РСУБД + без SQL + ODBMS + другие), DataNucleus поддерживает оба, Hibernate ограничен только JPA.
Производительность обновлений базы данных Hibernate
Еще одна проблема, которую следует учитывать при выборе ORM, - это эффективность его механизма грязной проверки - это становится очень важным, когда ему нужно создать SQL для обновления объектов, которые изменились в текущей транзакции. - особенно когда объектов много. В этом SO-ответе есть подробное техническое описание механизма грязной проверки Hibernate: JPA с HIBERNATE вставляет очень медленно
Любой, кто говорит, что JDO мертв, является торговцем астротурфингом FUD, и они это знают.
JDO жив и здоров. Спецификация все еще более мощная, зрелая и продвинутая, чем гораздо более молодая и ограниченная JPA.
Если вы хотите ограничиться только тем, что доступно в стандарте JPA, вы можете писать в JPA и использовать DataNucleus как высокопроизводительную и более прозрачную реализацию сохраняемости, чем другие реализации JPA. Конечно, DataNucleus также реализует стандарт JDO, если вам нужна гибкость и эффективность моделирования, которые предоставляет JDO.