Researching Spring-Data - I understand why you would use for NoSQL databases but am struggling why you would use Spring-Data for relational databases over the standard Spring-ORM capabilities (e.g. the JPA support as standard).
Anyone got clear use-cases why you would use the spring-data framework for relational queries?
Thanks,
James.
The JPA Module of the Spring Data project is different from the NOSQL ones as we don't need to provide a low level store abstraction ourselves. So the main features are:
elimination of a large chunk of the implementation code needed for repositories (see this blog post for a showcase)
abstractions for pagination and dynamic sorting
DDD specifications to allow defining domain predicates (see this blog post as example)
support for Querydsl predicates
transparent entity auditing
The JDBC module of Spring contains support for Querydsl as well.
Related
Even though MongoDB is a schema-less DB but there is a requirement in my project where I have to map my classes to the Database objects and prefer to have the data modelling for the same. Please suggest some Data-modelling tools for MongoDB to map the DB to Classes and Objects.
Moon Modeler is a data modeling tool for MongoDB and Mongoose (ODM)
I think you want to model your applications and persist your data in MongoDB. So it depends on what framework/language are you using for application.
I did a quick web search to get these ODM (Object-Document-Mapper) options recommended to work with MongoDB for some of the popular languages.
ruby
https://docs.mongodb.com/mongoid/master/
http://mongomapper.com/
java
https://github.com/mongodb/morphia
http://hibernate.org/ogm/
python
http://mongoengine.org/
http://api.mongodb.com/python/1.6/index.html
I'm interested in using Ming to model my 100+ GB data set which is largely non-relational data (signals measured in a lab) with some "relational" meta-data (e.g. experiment name) in MongoDB. This is not a question about whether or not I should be using a NoSql database.
If modeling relationships using an ODM (e.g. Ming's version here) is a valid design pattern than why aren't any of the other popular ODMs providing that functionality? I didn't see it in any of the following:
-Mongoose (MongoDB)
-cqlengine (Cassandra)
-Hector (Cassandra)
-doctrine (CouchDB)
It's definitely valid to model relationships in a NoSQL data store, although if you have highly relational data you might want to reconsider whether the data store and schema design you have chosen is working with or against your use case goals.
In MongoDB a common decision (based on your use case) is whether it might be more appropriate to model relationships by embedding related data in the same collection or using a reference linking to document(s) in another collection (see: Data Model Design in the MongoDB manual).
Foreign key relationships are typically not populated or enforced with server-side support from distributed NoSQL databases, so declarative references in an ODM often translate into multiple queries on the server. Multiple queries aren't necessarily bad (although there can be poorly written extremes) and an application-level data join using references can be very convenient.
For MongoDB in particular, there is a BSON field type for Database References (DBRefs). There is currently (as at MongoDB 2.6) no support for server-side expansion of DBRefs, however many of the drivers and ODMs provide convenience methods for following and populating references in this standard notation.
You can see this used in a few of the ODMs you've mentioned:
Mongoose supports population of documents from other collections
Doctrine ODM supports references mapping relationships to other classes/collections
Typically ODMs offer a choice of either automatic population of references or lazy population (i.e. as needed or accessed in code).
I'm not familiar with the Cassandra libraries, but didn't see any obvious mention of references or relationships in the documentation. I would assume that presence (or absence) of a relationship feature is more a choice of the author(s) of the ODM rather than a specific pattern/antipattern.
I am new to both Scala and NoSQL databases. I would like to know is if there exist ORM tools that will map my Scala objects to a NoSQL database, as with RDBMS solutions?
There is a library called Kundera, based on JPA, that provides ORM for a number of NoSQL databases of different flavours, including HBase, Cassandra, MongoDB, CouchDB and Neo4J. See https://github.com/impetus-opensource/Kundera which appears to be under active development. Note that the nature of some of the problems that have given rise to NoSQL in the first place, and some of the tradeoffs inherent in the CAP theorem between availability, consistency and partition tolerance, make ORM challenging in a NoSQL environment. There is some good discussion of some of these issues here: http://architects.dzone.com/articles/sqlifying-nosql-%E2%80%93-are-orm
As you mentioned Scala, specifically, here is a very interesting article from Foursquare about how they built DSL with Scala for interacting with MongoDB. http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/
I am trying to understand better EclipseLink NoSQL, but I am having trouble understand it's limitations, what it currently supports and I simply can't find anything about the future plans the team has.
So, in short, I have quite a big list of questions that i would like to know, if you people don't mind:
Does EclipseLink support:
Object Oriented queries
CRUD of entities
Polymorphic entities
Embeddable objects (components)
Basic types
Unidirectional and Bidirectional relationships (if yes, which ones?)
Collections (Set, List, Map, etc)
Full JPA support (I assume it does, but just in case I am wrong)
Denormalization
Complex joins and aggregations
Apart from these questions, are there any other limitations or jewels of the crown that I should know of?
Also, what is the team currently working in? What are the future plans?
I would be super happy if someone here could provide me with links or documentation for the questions I provided above, since I couldn't find anything :S
Thanks in advance, Pedro.
This depends on the NoSQL platform, for MongoDB a subset of JPQL and Criteria are supported (joins to external relationships are not supported)
Yes.
Yes, inheritance is supported.
Yes, Embeddables are supported, and ElementCollections (these are stored inline in the JSON document)
Yes
All unidirectional relationships are supported, bi-directional (mappedBy) is not supported, in NoSQL you just need to use two unidirectional relationships.
Yes.
Most of JPA. Some features such as joins, atomic transactions are not supported if the NoSQL platform does not support them (JPA transactions work, just rollback will not result in a rollback of any flushed changes if the database does not support transactions).
Yes.
Joins are not supported. Queries to embedded relationships is.
In an effort to complete the content of this discussion, I am now posting what I have found.
Currently (use discussion date as reference) EclipseLink Supports:
Complex hierarchical (including XML)
Indexed hierarchical data
Mapped hierarchical data (such as JSON)
CRUD operations
Embedded objects and collections
Inheritance
Relationships
Subset of JP-QL and Criteria API, dependant on NoSQL database's query support
Still needing answer:
Eclipselink limitations
Future plans
Sources:
http://www.eclipse.org/eclipselink/documentation/2.5/concepts/nosql001.htm#BJEIHEJG
http://wiki.eclipse.org/EclipseLink/FAQ/NoSQL
http://www.eclipse.org/eclipselink/documentation/2.5/concepts/app_tl_ext003.htm#CJAECHBD
http://www.eclipse.org/eclipselink/documentation/
I've started a new job where they are using mongodb in a java environment.
They have implemented a pattern using DTOs and factories with the morphia driver, this may be due to a migration onto mongodb from a key value store previously. The client is a JSON client.
It seems to me that the jackson-mongo-mapper would be a better approach because it's just mapping pojos from json to BSON and back, seems like it could do away with all DTO factory facade?
Anyone know any pros and cons with these different approaches?
Spring Data for Mongodb is very nice since you can use even another data store or mix them and repository interface is very helpful.
Kundera is an option through JPA2
http://agilemobiledeveloper.wordpress.com/2013/08/22/working-with-mongodb-using-kundera/
There's a lot of java to mongodb options.
http://www.agilemobiledeveloper.com/2013/01/31/hibernate-ogm-mongodb-vs-kundera-vs-jongo-vs-mongodb-api-vs-morphia-vs-spring-data-mongo-mongodb-drivers-for-java/
Adding your own data layer and making sure you use DI and test it fully is very helpful.
NOSQLUnit is awesome -> https://github.com/lordofthejars/nosql-unit
DTOs are good for keeping a separation between implementation and design, so when they need or want to switch from mongo to some other NoSQL or SQL database it can be done cleanly.