Could someone give me an explanation of if what I'm doing makes sense?
I am currently developing a Java EE application using MVC architecture, and MongoDB as my database. What I have is several entities written as Java objects with custom mapping methods to persist to and from my MongoDB, as well as a separate controller class to perform Database queries and operations. I am able to store these entities in my session with no problem, but I haven't tested this on a larger scale. I've tried annotating my objects as beans, however I received errors.
My typical method of transmitting data is to query my MongoDB, receive the information, map it to a java object, and store it in a session to be accessed by the front end. Is this the proper way to go about this?
Do my entities need to be EJBs? What do I have to gain from making them EJBs? I'm sorry if this question is presented poorly and seems unintelligent. I just want to have a better understanding of the technology I am trying to utilize before further developing. Most of the reading I have done on such topics has been to no avail. If anyone has some clear reading or an explanation that should help me understand what I am asking, it would be most appreciated.
I assume by "EJBs", you are referring to "Entity Beans"? In EJB 3, entity beans are "replaced" by JPA. Think of JPA as a "specification" for ORM frameworks. JPA/ORM are frameworks for mapping Java objects to and from relational databases. You are using MongoDB, which is not a relational database, and hence not that suitable for JPA. So I would say no, there is no need for you to consider JPA. Instead you should consider other frameworks, like Spring Data, which can simplify the task you are doing.
in my opinion you can use EJB3 with mongodb without JPA and entity manager, but you will have Stateless/Singleton/Startup/MDB beans with 0 configuration and with perfect managable backend.
Related
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
since my new project has to use toplink-essentials which only supports jpa 1, I'm looking for some good jpa-utilities. So far I only worked with jpa 2 (both EclipseLink and Hibernate), which didn't need any utilities to write dynamic queries in 99% of the time.
Now I'm stuck with jpa 1 and wondered if there were some utilities/libraries which could support me in writing my queries a little bit more dynamically.
Jonny
TopLink Essentials does support Expression queries which are similar to JPA 2 Criteria. You may be able to use them.
You should also be able to upgrade your server to EclipseLink.
We have a requirement for building a database crawler. The application parses the tnsnames, connects to each database and retrieves some information like version, accounts, etc. We are trying to use JPA across the other parts of the application and to persist this data into the application's database.
So far, I only see creating an EntityManagerFactory programmatically for every database. Is there any other options?
We are using Spring, are there any benefits that Spring brings to the table in this scenario?
Thanks
JPA is clearly not the right tool for this job. JPA allows creating functional entities mapping a well-know database schema. Your tool doesn't know anything about the schemas and tables it will find. There could be 0 tables or 5000, with completely unknow names.
You need a much lower-level API to do what you want, like JDBC.
You could use JPA to store the results of your crawlings in a single schema, though.
I have recently started getting familiarized with NoSQL (HBase). I am definitely a noob.
I was investigating about ORMs and high level clients which can be used on HBase and came across a few.
Some ORM libraries like Kundera are providing SQL like data query functionality. I am finding this a little counter intuitive.
Can any one help me understand why we would again need SQL like querying if the whole objective was to move away from it?
Also can anyone comment on your experiences with ORMs for HBase? I looked at a few of them from http://wiki.apache.org/hadoop/SupportingProjects and started looking at Kundera.
Another related question - Does data query with Kundera run map reduce jobs internally?
kundera or Spring data might provide user friendly ORM layer over NoSQL databases, but the underlying entity model still has to be NoSQL friendly. This means that NoSQL users should not blindly follow RDBMS modeling strategies but design ORM entities in such a way so that all NoSQL capabilities can be used.
As a thumb rule, the kundera ORM entities should be designed using query-first strategy where first the queries need to defined so as to create primary keys and also ensuring that relationship model is used as minimal as possible. Querying on random columns and full scans should be avoided and so data might have to be replicated across entities for reducing multiple entity look ups. Also, transactions management needs to be planned. FYI, kundera does not support transactions(beyond single row TX supported by Hbase/Cassandra).
Reason for using Kundera:
1) If looking for SQL like support over HBase. As it is build on top of HBase native API, so it simply transforms these SQL queries in to corresponding GET or PUT method calls.
2) Currently it support HBase-0.20.6 only. Kundera-2.0.6 will enable support for HBase 0-90.x versions.
3) Kundera does not do sometihng out of the box to provide map reduce over SQL like queries. However support for such thing will be provided in Kundera-2.0.6 by enabling support for Hive native queries only!
It is totally JPA compliant, so no need to learn something new. It simply hides complexity at developer level with very minimal effort.
SQL like querying is for developement ease, quick developement, less error prone and reusability ofcourse!
-Vivek
I am fairly new to the noSQL world, and although I understand the benefits of performance and "cloud" friendliness, it seems the RDBMS world is much simpler and standard and limited to fewer players
I worked with SQL Server, Oracle, DB2, Sybase, Terradata, MySQL and others, and it seems they have in common much more (in terms of Query language, Indexing, ACID, etc) than the noSQL family.
My question is mainly this
Is it at all a valid concept to move an existing Spring/Java EE+JPA app to a noSQL storage? or it will require a complete re-architecture of the system beyond the medium of storage?
Hoping it's a valid goal, are there any migration paths that were case studied as best practices?
Is there an equivalent to the concept in "noSQL" that is comparable to ORM for RDBMS? e.g. any layer of separating the storage implementation from concept (I know GAE BigTable supports JDO and JPA but only partially, is there a newer JSR for a more noSQL friendly JPA?)
Are there any attempts to standardize "noSQL" the same way RDBMS are (query language,
API)
Is "noSQL" a too wide term? Should I modify the question per implementation (KV/Document)
Try Kundera : https://github.com/impetus-opensource/Kundera. it is an open source JPA2.0 compliant solution. You can also join http://groups.google.com/group/kundera-discuss/subscribe for further discussion.
-Vivek
DataNucleus allows JPA persistence to RDBMS, MongoDB, HBase and various others. That is one way you can tackle the problem, giving you a start point for use of your app with other datastores. From there you could modify class hierarchies to get around some of the problems that these other datastores bring. Use of JPA with other datastores is not part of any JSR and never will be, since JPA is designed around RDBMS solely. JDO on the other hand is already a standard for all datastores, as it was designed to be (also supported by DataNucleus)
EclipseLink 2.4 supports JPA with MongoDB and other NoSQL data sources.
http://java-persistence-performance.blogspot.com/2012/04/eclipselink-jpa-supports-mongodb.html
PlayOrm is another solution with it's Scalable-SQL and is JPA-like but breaks from JPA in that it supports noSQL patterns that JPA can't support.