I'm working on a Java webapplication and want to access the database (PostgreSQL) via an database API for security reasons. The API of the database is built by database functions.
How can I call the API functions with an EntityManager? I figured out a way with native queries, but I think then there is not much left of ORM. Is there a way for example to lead the entityManager.persist() method to one of the database functions?
This is not a good idea. The entire point of JPA is to standardize the way the database is accessed and mapped to the Object layer. If you want to use native DB functions then you should use JDBC, possibly via SpringJDBCTemplate or some other tool that eases some of the pain. If you really feel like punishing yourself though, you could always create your own implementation of EntityManager and use that in your classes.
Related
I am writing a java application in which I am using Spring Boot and JPA in order to map classes to my database tables.
However, due to a somewhat complex database structure I also have the need of creating custom queries that are not mapped to any specific POJOs / Entities.
Therefore I am using PreparedStatement together with a DataSource with #Autowired annotation.
It hit me that using both of these DB Access methods might not be suitable to use together?
So far everything has worked out in my dev environment, but are there any pitfalls that I should look out for when using both of these together or is there a preferred way of doing custom queries when using JPA?
It should be noted that my database calls are fairly short and happen in a stateless manner, so there should hopefully not be any problems with interfering sessions (?)
JPA EntityManager will not know anything about your changes made with PreparedStatement. This will cause issues with JPA built-in caching, maybe with versioning and also with transaction support.
Though you may need to check this question: Is it OK to use both JPA (for normal CRUDs) and JDBC (for batch update & call stored proc) in the same project
Invan's answer makes a clear point.
On the other hand your fine when:
you need complex queries to SHOW data (read only).
you infrequently need to do some batch updates and do a clear cache entityManager.getEntityManagerFactory().getCache().evictAll()
When developing for Microsoft Visual Studio and MS SQL Server, I would create stored procedures in MS SQL Server and a dataset in VS. The dataset is created with a wizard that effectively creates classes that my C# code can use to execute stored procedures and read data from the database. What is nice about this is that the classes abstract the interface with the database and provide an object oriented way of dealing with the database. The creation of classes from datasets guarantees strongly typed fields that are bound to actual database columns, which is really good. The real beauty with datasets is that if you change the database and refresh your dataset, it automatically rebuilds the classes. This prevents you from having a wrong data type in a class if you were to manually create those classes.
Is there something equivalent in Java / Eclispe development when working with a mySQL database? JDBC isn't an object oriented approach, so I'm wondering what alternative there is.
The most common way to communicate with a database in Java is probably to use an ORM framework such as Hibernate, possibly together with JPA. Hibernate abstracts database tables to Java classes, and uses JDBC under the hood.
Is there something equivalent in Java / Eclispe development when working with a mySQL database? JDBC isn't an object oriented approach, so I'm wondering what alternative there is.
Hibernate has a reverse engineering feature (Hibernate Tools). It allows you to automatically create Java classes from your database. Alternatively, you can let Hibernate create the database tables for you, which is specified by this parameter hibernate.hbm2ddl.auto=update.
This would probably be a good starting point.
I'm trying to find a good way to implement a generic search API in Java that will allow my users to search the backend repository without needing to know what that backend technology is, and so that if in the future we switch vendors I can reimplement the underlying logic without needing to recode the API. The repository underneath could be a relational database or a document store like SOLR, CouchDB, MongoDB, etc... It would need to support all the typical search requirements such as wildcards, ranges, bitwise operators, and so on.
Are there any standard ways of approaching this problem?
Would JPA be my best bet? Would it do everything I need it for, including non-relational databases?
Thanks in advance!
What you need is a ORM framework like Hibernate, if you go for JPA, you need to re-invent a lot of wheel.
using Hibernate you can write the business logic for searching the backend database or repository without vendor specific implementation, and if later you need to change the backend, you can do it without affecting your existing business code implementation.
I would advice you to check the hibernate documentation for further reference
The Spring Data umbrella of projects provides a nice DAO abstraction named CrudRepository. I believe most of the sub-projects (JPA, MongoDB, etc.) provide some implementations of it.
JPA would be one of a number of implementations you would use to map your relational database to objects. It would not protect you from database changes.
I think you're looking for the DAO Pattern. What I'm doing is as follows:
Create an interface for each DAO
Create a higher level DAO implementation that simply calls my actual database specific implementation
Wire the higher level DAO implementation to the database specific implementation with Spring.
This way, no code anywhere touches database specific implementation. The connections are formed only in XML.
JPA is designed around RDBMS ... only. Using it for other types of datastores makes little sense since things likes its query language leak SQL syntax. JDO is designed for datastore agnoticity, and provides persistence to many datastores using its implementations such as DataNucleus, though not all of those that you mention.
JPA is designed around RDBMS, Hibernate is also designed for RDBMS. There are few implementations of JPA which support no-sql. Similar projects are built around hibernate to support no-sql databases. However the API itself is tuned for RDBMS.
Implemeting a DAO patterns would require you to write your own query api. Later extend the implementation when ever your data store changes.
JDO and DataNucleus is ground up designed for heterogeneous data stores. Already has support for a dozen stores ,plus RDBMS. Beauty is that the query api remains constant across the stores. JDO allows you to work with domain model and leave the storage details to implementations like DataNucleus.
Hence I suggest JDO api with datanucleus.
The below link gives list data stores and f features already available in DataNucleus
http://www.datanucleus.org/products/accessplatform_3_0/datastore_features.html
As far as I know, there are the following data access storage options:
JDO
JPA
Entities, Properties, and Keys
Which one are you using and why? I am new to all of these and do not know which one is best ... It would be nice, if someone could show me the stumbling blocks in all these options?
Until now I would prefer Enteties, but I don't know how to implement the data model efficient?
Thanks
I avoid JDO and JPA because they give developers false feeling that Datastore is a relational database. People use JDO/JPA because they know them from the SQL world and as far as I have seen it can be non-optimal because Datastore in anything but a relational/SQL database.
You really should understand how Datastore works and use API that is native.
So, the only left options are low-level API (entities, properties, keys) or objectify.
While low-level API gives you all Datastore capabilities, it forces you to use Entities instead your classes. So you end up writing a lot of boilerplate code that does copying between Entities and your objects.
Objectify, was designed specifically for AppEngine Datastore and internally uses low-level API, so it has all the features and speed without any of the drawbacks. You should really give it a try.
Update:
There are alos other options similar to objectify (similar in a sense that they were made specifically for datastore): Twig and SimpleDS. See this for comparison: Looking for opinions on using Objectify-appengine instead of JDO in GAE-J
There is only one storage option. GAE offers a JDO and a JPA API on top of the datastore, but it's just a different way of accessing the datastore (like Hibernate, JDO and JDBC are three different APIs that can be used to access a RDBMS).
I am developing a project at Java fresher level.
I had to implement database interaction using Hibernate.
At the first stage, I started using HQL query language. But, later I come to know about Criteria queries through my previous questions.
But, still after learning Criteria, I am not getting what are the steps I should follow to fill and fetch data to and from database.
In fact, what are the packages and classes I need to develop manually and the script or query I need to write to fill/fetch data if I am given a database and table in it, using Criteria ?
Please also tell me, where would be difference when I use different database like PostGresql or MySQL within steps.
In fact, what are the packages and classes I need to develop manually and the script or query I need to write to fill/fetch data if I am given a database and table in it, using Crieteria?
Create an object model and map it to the tables using either annotations or xml mapping files. Classes that can be persisted are called Entities. Using the reverse engineering module of Hibernate Tools, it is possible to generate them.
Create instances of entities, set their attributes and use session.persist(Object) to persist them to the database to "fill data". Use the Criteria API to read from the database and fetch data. Data access is typically done in a data access layer using the DAOs pattern. DAOs expose finders and CRUD methods (Create, Read, Update, Delete).
If all this is new to you, I'd suggest to use Spring, it provides useful support classes and will help you to structure your application following the above pattern. Have a look at the Chapter 12. Object Relational Mapping (ORM) data access.
Please also tell me, where would be difference when I use different database like PostGres or MySQL within steps.
If their physical model differs, you may have to change the mapping of entities. Apart from that, switching from one database to another would require using the appropriate JDBC driver, changing the connection string and the Hibernate dialect (i.e. this is more a matter of configuration).