want to develop my project on Google App Engine .I want to use google big table as database. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Since you're using Data Nucleus, see their FAQ on JDO vs JPA. http://www.datanucleus.org/products/accessplatform_3_0/jdo_jpa_faq.html
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
A key difference is that JDO support a rich domain model (logic together with data), in fact all persistent classes can have a reference to the current PersistenceManager, issue queries, and, I guess, it's possible not to have fields persistent by default.
JPA does not support such software design. In fact each Entity doesn't have a reference to the PersistenceManager, to have it you have to resort to ThreadLocal variables, which is not a very elegant and robust solution.
Since GAE BigTable is not an RDBMS, JDO is a better choice. There are some detailed comparision articles in Aphache JDO, it is helpful for me.
JPA persists java objects to relational data via ORM, while JDO is more general specification for java object persistence. So using JDO will give you more freedom in storage implementation options for your objects.
JPA is the leading java standard for persistence. So I'll say use JPA if you are using RDBMS and require ORM.
Hibernate is generally used as JPA implementation. If you need some extra features you can use hibernate specific annotations.
This question already looks to be discussed here JDO vs JPA for Java on Google App Engine
Related
I notice SDN4 has the concept of repositories and annotations for cypher queries, but this seems not much more than programming style? Neo4j-OGM seems straight forward, easy to set up, with a really practical and efficient API. I'm wondering why both projects exist. Are there any real differences between the two?
Spring Data Neo4j
http://projects.spring.io/spring-data-neo4j/
Neo4j OGM
https://neo4j.com/docs/ogm-manual/current/introduction/
The idea behind having separate projects is to enable as many developers as possible to integrate their JVM-based applications easily with Neo4j.
The two projects are closely related: Spring Data Neo4j's implementation is actually backed by the Neo4j OGM codebase. The Spring Data Neo4j project extends the capabilities of the OGM by allowing developers to work with familiar concepts - Repositories, Transactions, Templates, Derived Queries and so on.
However for developers who don't want to (or cannot) use the Spring stack, having a separate OGM project means they do not get shut out from using Neo4j.
I want to create an project and using MongoDB and Neo4J, both databases are need to use. Now the day's Hibernate OGM concept was launch and support provide for all NoSQL databases. If i am go for Hibernate OGM they used JPA apis for implementation and it is easy user for Hibernate users. If i am go for Spring-Data, we need to configure both Spring-Data MongoDB and Spring-Data Neo4j and use Spring-Data apis for that. My team is confuse for which technology we go Hibernate OGM or Spring-Data. We focus on some points and Go for Spring-Data. Points are as below:
Spring-Data is a early concept, the support for Spring-Data is easily provide at online forums but Hibernate OGM is new.
Spring-Data have various features for NoSQL databases, but for Hibernate OGM we are not sure all feature are provided that mention in this slide.
Hibernate OGM use JPA queries and JPA queries translate according to NoSQL vendor query and i think this cause performance issue. But in Spring-Data we easily user Cypher Queries and Mongo Template.
I am also confuse for Hibernate OGM have full support for Graph Db feature like maintain attributes of relationship?
Please suggest me for which technology we need to go.
If you choose to use two different NoSQL databases on a same project, it's probably because you really really need of their uniq features (geo-spatial queries on MongoDB, being able to execute graph traversals for Neo4j, and so on).
So Hibernate OGM is clearly NOT for you. You can use directly native API of Mongo and Neo4j. Or you can use Spring Data that claims to provide a consistent programming model (but not a single API).
I thought about using a graph database for my new project. It's
a project with many social relations and many other things which
can easily be represented by a graph.
Graph-Databases are much faster so I started thinking about it.
However, I have a Java Enterprise Web Application and I have been using
(until now) a relational MySQL Database with JPA.
Now my question: Is there already the same JPA functionallity
for Graph-Databases like there is for relational Databases?
I would like to use Neo4j or OrientDB.
DataNucleus JPA provides persistence to Neo4j. Supports basic relationships and an amount of Cypher query capabilities, and there is a tutorial for use with JPA (as well as JDO). Open to contributions to push it further.
OrientDB also provides an amount of support for JPA annotations direct IIRC.
I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/
I'm looking for a common data access framework that will provide portability across various nosql databases like SimpleDB, Azure Tables, Cassandra, CouchDB, MongoDb, etc. I'm building an app and would like my customers to be able to use which ever nosql store they want.
In a more relational scenario, I'd use Linq over nHibernate or Entity Framework, but I haven't found an equivalent framework for nosql databases. All I've found is database specific API's even though there seem to be significant commonality. Does one exist? Preferably one with LINQ.
No these things are too different and too specific (at least right now). If you wanted something really simple, like just a wrapper on an object that is only accessed by ID, then you may have a hope. In fact, if you look at NoRM, it may be possible to adapt that to various providers.
However, outside of a small core set of features, these "NoSQL" databases are quite different in many regards. I mean, how do you implement the various map/reduce functions agnostically? How do you implement atomic operations when they support different atomic operations?
Either way, we're way too early in the NoSQL life-cycle to have an agnostic framework for all of this. Azure basically dropped their NoSQL offering in favor of "hosted SQL server". MongoDB is maybe 20 months old, CouchDB is still on version 0.11.x, SimpleDB is less than 24 months old, Cassandra is on version 0.6.2 and has maybe been in regular use for a couple of years.
We're just not there yet.
A common query language (called UnQL) is being developed: http://www.unqlspec.org/display/UnQL/Home
There are LINQ providers for MongoDB but I don't think that there is a generic .net linq provider to 'all' nosql db's .
Some people have contemplated about a generic nosql query language: http://nosql.mypopescu.com/post/731261002/a-common-nosql-query-language
If you only have basic persistence persistence requirements, I maintain a common caching API with providers for Memcached, Redis, InMemory and FileSystem caching.
It only supports Redis, but I have a C# Redis Client that has a very familiar C# API. It natively supports persisting POCO types and exposes all of Redis's advanced server-side data-structures as native .NET IList, ICollection data structures so they can easily be used in existing C# APIs like LINQ, etc.