ORMLite - заставить объекты чтения иметь одинаковую идентичность

Я читаю иерархию объектов с помощью ORMLite. Он имеет форму дерева, у родителей есть @ForeignCollection из 0+ дочерних элементов, и каждый дочерний элемент ссылается на своего родителя с помощью @DatabaseField(foreign=true). Я читаю и сохраняю сразу всю иерархию.

Поскольку я новичок в ORM в целом, а также в ORMLite, я не знал, что при чтении объектов с одним и тем же идентификатором в базе данных они не будут создаваться как фактически один и тот же объект с одним и тем же идентификатором, но как несколько дубликатов с одним и тем же идентификатором. Это означает, что теперь я столкнулся с проблемой, что (скажем, «->» означает «относится к») A -> B -> C != C -> B -> A.

Я думал решить эту проблему, вручную прочитав их через предоставленные DAO и собрав их вместе по идентификатору, убедившись, что объекты с одинаковым идентификатором имеют одинаковую идентичность.

Есть ли ORMLite-родной способ решения этой проблемы? Если да, то что это, если нет, то каковы общие способы решения этой проблемы? Является ли это общей проблемой ORM? Есть ли у него название (я хотел бы узнать о нем побольше)?

Редактировать:

Моя иерархия такова, что одно здание содержит несколько этажей, где каждый этаж знает свое здание, и каждый этаж содержит несколько зон, где каждая зона знает свой этаж.


person riwi    schedule 14.07.2011    source источник


Ответы (2)


К сожалению, нет родного для ORMLite способа решения этой проблемы. Более сложные системы ORM (такие как Hibernate) имеют уровни кэширования, которые существуют специально по этой причине. ORMLite не имеет уровня кеша, поэтому он не знает, что он только что вернул объект с тем же идентификатором «недавно». Вот документация по кэшированию Hibernate:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html

Однако ORMLite разработан как Lite, и слои кэша нарушают это обозначение IMO. Единственное [неудачное] решение вашей проблемы в ORMLite, которое я вижу, - это делать то, что вы делаете, - перестраивать дерево объектов на основе идентификаторов. Если вы предоставите более подробную информацию о своей иерархии, мы сможем помочь более конкретно.


Итак, немного подумав о вашем случае @riwi, я понял, что если у вас есть здание, содержащее коллекцию этажей, нет причин, по которым объект здания на каждом из этажей в коллекции нельзя установить с помощью родительский объект Building. Дух. В ORMLite есть вся необходимая для этого информация. Я реализовал это поведение, и оно было выпущено в версии 4.24.

Изменить:

Начиная с ORMLite версии 4.26 мы добавили первоначальный подход к кэшированию объектов, который может поддерживать запрашиваемые функции. Вот документы:

http://ormlite.com/docs/object-cache

person Gray    schedule 14.07.2011
comment
Спасибо, Грей, это уже помогает. Я отредактировал свой исходный пост, чтобы объяснить свою иерархию (по крайней мере, три наиболее важных объекта домена). - person riwi; 14.07.2011

Является ли это общей проблемой ORM? Есть ли у него название (я хотел бы узнать о нем побольше)?

Это общий шаблон для ORM, который называется «Карта идентификации»: в сеансе, независимо от того, где в вашем коде вы получили сопоставленный объект из ORM, будет только один объект, представляющий определенную строку в БД (т.е. имеющий это первичный ключ).

Мне нравится этот шаблон: вы можете получить что-то из базы данных в одной части вашего кода, даже внести в него изменения, сохранить этот объект в переменной экземпляра и т. д. А в другой части кода, если вы овладеете объект для той же «строки БД» (любым способом: вы передали его в качестве аргумента, вы сделали массовый запрос к БД, вы создали «новый» сопоставленный объект с тем же первичным ключом и добавили его к сеансу), вы получите тот же объект. - Даже прежние модификации (в том числе непрошитые) будут.

(из-за этого добавление сопоставленного объекта в сеанс может завершиться неудачно, и в зависимости от ORM и языка программирования это добавление может вернуть вам другой объект как «тот же самый»)

person Robert Siemer    schedule 22.07.2011