Morphia — легкий ORM для MongoDB, управляемый аннотациями

[@shponarsky]

Всмысле оно заточено чисто под mongoDB?

[@FractalizeR]

Да, именно так.

[@solver]

Спасибо.
Как раз искал что-то подобное.

[@malexejev]

Только не ORM, т.к. монго — не реляционный сторедж.

[@dxb]

Ну я бы сказал, что на уровне объектов реляционность все же присутствует. Mongo поддерживает поиск по структуре документа, поэтому на документы можно мапить довольно сложные структуры. То есть в терминах Mongo документ один, а программист-клиент работает с набором связанных объектов.

Вообще можно очень условно рассматривать каждый монговский документ как олап кубик. Такую структуру можно описать даже стандартным набором JPA аннотаций. Может, замутить стартапчик?

[@malkolm]

не перевирайте термин

[@FractalizeR]

Который?

[@dxb]

Не путайте отношение (relation) и таблицу. Да, это одно и то же с точки зрения реляционной СУБД. Но ORM — это механизм, позволяющий создавать виртуальную реляционную структуру на уровне объектов, и ему вовсе необязательно иметь нечто реляционное в качестве хранилища данных. Это просто на один уровень абстракции выше.

[@dxb]

Да почему же поверх физической реляционной базы данных? ))) Бэкэнд может быть любым. Я понимаю, что мои слова для Вас не авторитетны, может быть эта ссылка Вас переубедит?

[@dxb]

Я ни в одном своем комментарии не употреблял термин «реляционный» в смысле «связочный». Мне надоел этот спор ни о чем с подменами тезисов. Я сдаюсь.

[@FractalizeR]

Я не знаю, из чего вы исходите, но вы явно противоречите определению WikiPedia. Там ясно написано

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages.

Нет здесь ничего про «реляционный». Я надеюсь, у вас нет монополии на разъяснение смысла IT терминов? И вообще, зачем цепляться к словам? Употребили термин и употребили. Все поняли в каком значении.

[@dxb]

Уже писал Денису в личку. частично продублирую сюда:

Перечитал свой первый комментарий. Пожалуй да, он допускает и такую трактовку. Попробую переформулировать то, что я имел в виду в первом и втором комментариях: Отношение это не всегда таблица РСУБД. Это логическая сущность. И в Монго отношения представляются в виде документа или его части. Поэтому я и приводил олап кубы как наиболее, как мне кажется, наглядный пример того, как отношения из обычной РСУБД разворачиваются в структуры подобные документам монго. Но логические отношения-то из них при этом не исчезают! А ORM мапит именно объекты именно на отношения. Все верно.

[@FractalizeR]

Я понял вашу трактовку. Однако «давайте разберемся» и "я трактую" у меня как-то плохо согласуются. Вы можете чем-то подкрепить свое мнение? Скажем, я слово Relational в аббревиатуре ORM перевожу как производное от «связь», а не «реляционный». Да и слово «реляционный», в общем-то говоря, суть «выражающий отношение».

В реляционной теории слово «таблица» — неформальное. Ключевое слово в реляционной модели данных — «отношение». В оригинальной работе Кодда, с которой, собственно, все начиналось, слово таблица (table) вообще встречается всего дважды в самом начале.

Я термин Object Relational Mapping трактую так: отражение объектов на отношения, где под отношениями подразумеваются таблицы РСУБД

В самом термине про РСУБД нет ни слова. И под отношениями вообще-то должны пониматься именно отношения. А вовсе не таблицы, которые эти отношения вообще говоря реализуют.

[@FractalizeR]

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

Откуда вообще взялось это выражение? Ваш дословный перевод с английского термина «Object/Relational Mapping»? На мой взгляд, перевод неграмотный. Я бы сказал, что это переводится как «отображение объектов и связей [между ними]». Кстати, вообще это интересный аргумент в споре — перевести термин с английского дословно, получить ахинею и утверждать, что термин не имеет смысла.

Мы же про базы данных говорим?

Кто говорит? Я говорю про информацию и ее хранение. Но даже если бы мы говорили о базах данных, они бывают не только реляционными.

In relational model:
A relation is a data structure which consists of a heading and an unordered set of tuples which share the same type.

Ткните пальцем, пожалуйста, где тут конкретно сказано про таблицы.

[@FractalizeR]

Хорошо, докажите, что я перевел не правильно, и я соглашусь. Ваша трактовка странная и я ее впервые слышу.

Это сделать довольно легко. Вы сказали

Я это могу подкрепить тем, что выражение «отображение объектов на связи» не имеет никакого смысла.

То есть, вы сами признали, что ваш перевод не имеет никакого смысла. Но сам термин смысл имеет, раз он используется во всем мире. То есть, вы перевели его некорректно. Полагаю… ЧТиД?

Да. В теории баз даных есть сетевые модели, к примеру. И что это меняет?

Мы говорили не о теории баз данных, а о самих базах данных, которые бывают разными. В том числе и «объектные, объектно-ориентированные, объектно-реляционные».

«unordered set of tuples which share the same type.»Вполне понятно, что это синоним таблиц.

Из чего именно это становится понятно? Коллекция MongoDb, каждый документ которой имеет один и тот же формат вполне является «unordered set of tuples which share the same type».

[@FractalizeR]

Нет, докажите, что перевод «отображение объектов на таблицы» не верен, а верен какой-то другой.

Не понимаю, почему я должен что-то доказывать, а не вы. Это ведь вы ратуете за исключительно однобокое толкование термина ORM, а не я. Я считаю, что термин ORM можно применять как к реляционным базам данных, так и к любым другим, которые могут хранить отношения между сущностями. Поэтому справедливы оба толкования этого термина.

Но дело в том, что такая коллекция документов одного формата не является основной структурой для монго.

Причем тут является основной структурой или нет?

Коллекция MongoDb, каждый документ которой имеет один и тот же формат вполне является «unordered set of tuples which share the same type».

Вы можете оспорить мои слова или нет? Зачем увиливать?

[@FractalizeR]

Отображение объектов и связей — объекты подразумевают связи, инче это не объекты.

Полностью с вами согласен. Только вот связи можно хранить не только в реляционных базах данных.

Я не нашел примеров ORM, которые меппят не на таблицы.

Ну вот Morphia например :)

Ну коль вы дошли до такой аргументции, то удачи.

Так ведь это ваша аргументация :) «Я считаю, что термин ORM можно применять только к реляционным базам данных» — ваша? Или нет?

На сайте Morphia нет упоминания, что это ORM

Читайте тред внимательно. Вы слишком увлеклись нашим маленьким спором.

[@FractalizeR]

Вы куда смотрите-то? На той странице вообще слово ORM не встречается. Термин «Object/Relational Mapping» там вообще никак не толкуется, практически. Только ссылка на Wikipedia справа. Там сказано

Specifically, Hibernate is concerned with data persistence as it applies to relational databases (RDBMS)

И все. А далее

In the world of Object-Oriented applications, there is often a discussion about using an object database (ODBMS) as opposed to a RDBMS. We are not going to explore that discussion here. Suffice it to say that RDBMS remain a very popular persistence mechanism and will so for the foreseeable future.

То есть спорить попусту, как это делаете вы, они не намерены :)

Кстати, если вы подозреваете в большом количестве ошибок Wikipedia, почему бы не предположить тоже самое в отношении Hibernate? Тем более, что у них ссылка на Wikipedia справа поставлена. Значит, они доверяют мнению Wikipedia, раз на нее ссылаются?

[@FractalizeR]

Открываю Google и ищу «object relational mapping mongodb». Нахожу, например:

Grails Object Relational Mapping for MongoDB

В общем, с вами все ясно :)

[@FractalizeR]

Поясните, пожалуйста, я не совсем вас понял.

[@ad_Wolf]

Да, правильно называть ODM

[@FractalizeR]

Надо автора проинформировать, а то он, бедный не в курсе: blog.mongodb.org/post/5217011262/improving-scalable-java-application-development-with-mon

[@aib]

Поддержка GWT — это УГ которое не работает и не собирается к сожалению.

[@PATRICK17]

ну у кого как

[@aib]

Пробовали и в проекте работало? entity с ObjectId нормально собирались?

[@qmax]

извиняюсь за оффтоп, я из другого мира, мимо проходил.

аннотации — это конструкции вида @foo decl?
чтоли в жаве есть рефлексивность?

[@eeccho]

Конечно. И аннотации, и рефлексия.

[@qmax]

Правильно ли я понял, что аннотации — это типа програмно-читабельных комментариев, а рефлексия ограничена интроспекцией?

[@dxb]

первое — с небольшой натяжкой да, а второе — нет. Есть и манипулирование данными, и динамическая компиляция, и подмена байткода, и многое другое.

[@dvolk]

А есть где-нибудь сравнение Morphia и Spring Data?

[@FractalizeR]

stackoverflow.com/questions/5837135/how-do-morphia-mongo4j-and-spring-data-for-mongodb-compare

SpringData для Mongo пока еще в MileStone состоянии находится. Кстати, 10Gen наняли одного из разработчиков Morphia.

[@MercurieVV]

Лично мне кажется что очень не хватает JPA имплементации. Это же хорошо когда есть стандарт и люди его придерживаются (даже если не полностью).

[@ProgMonster]

"@Serialized EncryptedReviews;"

Имя поля класса забыли.

[@kvieserc]

Скажите, а Вы эту штуку в деле пробовали. На сколько она работоспособна. Есть ил какие трудности?

[@FractalizeR]

Нет, сам не пробовал, к сожалению.

[@Vitamon]

Мне сначала очень понравилась возможность работать с mongoDB с помощью аннотированных классов. Но фишка mangoDB — в динамичности структуры entity. При использовании же заранее определенных классов с аннотациями, мы пытаемся работать с noSQL как с обычной реляционной базой, что нивелирует преимущества подхода. Как по мне, нужно либо динамически строить объекты у которых нет заранее заданной структуры и сохранять их в монге, либо уж по старинке использовать SQL+Hibernate+Spring и не заморачиваться.