I have seen some documentation on connecting to more than one database/data source via JPA, but this is not what I want to do exactly. I want to use one database provider for development and a completely different database provider for production (and probably QA). This question would also be applicable to supporting different production environments with different database providers (ie, DB2 for Client 1, Oracle for Client 2, MySQL for Client 3, etc).
In my case, I would like to do the following:
use JPA with Apache Derby for development purposes
use JPA with IBM DB2 for production purposes
We do not use Spring :(
With MyBatis, I could simply provide XML mappings for each database I wanted to support. And map all of results back to the same entities/POJOs.
So far it seems to me, that JPA will require custom everything up to maybe the Service layer (with entities, DAO, sql all being custom per database).
I want to know how you would go about setting up your application to use Derby for development and DB2 for production. Can I get by with using the same entities for both, should I separate the DAO layer into separate projects, can I use one persistence.xml, etc.?
Please let know what approach you would suggest to accommodate this.
This is a pretty common scenario, you don't need to duplicate anything if you are using JPA properly. You can use the same #Entity classes and DAOs.
If you are using Maven you can make the connection settings specific to some Maven profile, e.g. create profile for each environment and then let Maven resource filtering populate properties in your persistence.xml file (see this answer).
Related
I have seen instances where developers create tables in the database then they use jpa tools to generate entities from the tables. There are also cases where entities are first created then the tables will be created by the JPA provider. Which is the best approach?
When I learnt java ee web I used the jpa provider to create entities for me in the database.
Both approaches work. This poll by JPA Buddy shows that 56% of developers manage their data model in the database and then synchronize DB tables with JPA entities, while 44% develop the data model as JPA entities and update the database in accordance with modifications in Java code.
So, there is no right answer to your question. If you fully control your database you can follow any path you prefer. Note, that JPA tools will fully regenerate your classes. You can use IntelliJ IDEA you can use JPA Buddy which provides a cherry-pick way to upgrade your entities.
If you follow the entity first approach, you will need to upgrade your database accordingly using some DB versioning framework like Flyway or Liquibase. Make sure you don't use auto-dll by hibernate in production as it is explained in this tutorial.
If you are given the database, you have no option other than reverse engineer tables into entities.
Bit of a noob question I'm afraid. I have an ASP.NET Core Web Application, which uses Individual User Account for authentication so it's brought in the Identity bits and created me migrations and an "ApplicationDbContext" for all of the user/roles stuff. I moved the Data related classes, migrations etc into a separate class project to separate it from the MVC project, but other than that it's out-of-the-box. All good. My DB has been created by migrations and I can register and login.
Now, I'm coming to build my app, and I'm not sure where is best to add my entities. The question is should I
1) Add my entities to the "ApplicationDbContext" which was created for me by Visual Studio?
2) Create a second DbContext instance in my Data project?
3) Something else?
I understand that if my app was to use separate databases for authentication and domain data then it would be a no brainer and option 2 would be the answer. But this app is very simple with one database, so I'm wondering if I may be able to get away with option 1.
The ApplicationDbContext that was created for me inherits from IdentityDbContext. I don't know if that has other implications if I were to go with option 1 and add my entities to ApplicationDbContext.
I did start down the road of option 2, but quickly found that things like Add-Migration wouldn't work when the project had 2 contexts. I found that the Add-Migration command now has a -context switch which can be used to tell the command which context to use, but I'm a bit concerned that I will run into other issues. Particularly I am going to be using VS Team Services to build and deploy the app to Azure using continuous deployment, and I don't know if those build and release features will cope with the multiple DB contexts.
Any advice from somebody in the know? This has got to be a pretty standard requirement, right?
Hence your app is very simple one,you can use ApplicationDbContext for your domain models as well.That means, I would like to recommend you to use single context class for your app.If you do so,you can easily manage your business requirements (i.e. any relations between your classes) with the users and Roles on the IdentityDbContext context.
I'm wondering if it is possible to specify SimpleJPA as the persistence provider used by Spring-Data-JPA. I'm not a JPA expert so I hope this question isn't silly. Is it as easy as just specifying SimpleJPA's entity manager factory in the persistence.xml? I have yet to find anywhere online where someone has used Spring-Data-JPA to connect to Amazon's SimpleDB, I would love it if someone could point me in the right direction.
I just found this project and got it working for our Spring Data + SimpleDB needs:
https://github.com/3pillarlabs/spring-data-simpledb
The documentation is pretty good and getting things up and running was pretty straight-forward. I was accessing SimpleDB via Spring Data with about 10 minutes of work.
Generally setting up your persistence provider is just a matter of setting up the EntityManagerFactory through your Spring context (in case you use the Spring container). Thus have a look at how to configure EntityManagerFactory instances in Spring.
There might be the need to implement a custom JpaVendorAdapter to let Spring use the SimpleDB JPA implementation correctly. For some advanced functionality (e.g. using pagination with manually defined queries) we'd have to tweak the Spring Data JPA codebase a bit. If you'd like to see that supported feel free to open a ticket in our JIRA.
I'm trying to write a Java EE 6 application using JPA but without using Hibernate or Spring. I used Netbeans to generate the JPA classes, and I created the tables in Postgres, but I am not able to run DbUnit tests in those JPA classes.
I have tried to base my test unit on the example described in this site: http://www.roseindia.net/testingtools/DbUnit/gettingstarted.shtml but it does not work. I keep getting a "java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory" even though I added slf4j to the project libraries in the IDE.
One thing that I find rather odd about the roseindia site example is that it does not seem to have a caller object for the test object created. I am not sure if a caller object is even needed (complete n00b in JavaEE programming, and kind of lost still).
If you choose to use entities (java classes annotated with #Entity, representing database records), you have to use some JPA provider. You are not restricted to Hibernate, though.
If you're frightened by JPA, your other option is to use plain JDBC. It is far easier to understand, if it's your learning-exercise application, it might be a good idea to try and see how it works. JPA is built on top of JDBC, so when you think you're ready for it, you'll have a solid knowledge base.
I really like OData (WCF Data Services). In past projects I have coded up so many Web-Services just to allow different ways to read my data.
OData gives great flexibility for the clients to have the data as they need it.
However, in a discussion today, a co-worker pointed out that how we are doing OData is little more than giving the client application a connection to the database.
Here is how we are setting up our WCF Data Service (Note: this is the traditional way)
Create an Entity Framework (E)F Data Model of our database
Publish that model with WCF Data Services
Add Security to the OData feed
(This is where it is better than a direct connection to the SQL Server)
My co-worker (correctly) pointed out that all our clients will be coupled to the database now. (If a table or column is refactored then the clients will have to change too)
EF offers a bit of flexibility on how your data is presented and could be used to hide some minor database changes that don't affect the client apps. But I have found it to be quite limited. (See this post for an example) I have found that the POCO templates (while nice for allowing separation of the model and the entities) also does not offer very much flexibility.
So, the question: What do I tell my co-worker? How do I setup my WCF Data Services so they are using business oriented contracts (like they would be if every read operation used a standard WCF Soap based service)?
Just to be clear, let me ask this a different way. How can I decouple EF from WCF Data Services. I am fine to make up my own contracts and use AutoMapper to convert between them. But I would like to not go directly from EF to OData.
NOTE: I still want to use EF as my ORM. Rolling my own ORM is not really a solution...
If you use your custom classes instead of using classes generated directly by EF you will also change a provide for WCF Data Services. It means you will no more pass EF context as generic parameter to DataService base class. This will be OK if you have read only services but once you expect any data modifications from clients you will have a lot of work to do.
Data services based on EF context supports data modifications. All other data services use reflection provider which is read only by default until you implement IUpdatable on your custom "service context class".
Data services are technology for creating quickly services exposing your data. They are coupled with their context and it is responsibility of the context to provide abstraction. If you want to make quick and easy services you are dependent on features supported by EF mapping. You can make some abstractions in EDMX, you can make projections (DefiningQuery, QueryView) etc. but all these features have some limitations (for example projections are readonly unless you use stored procedures for modifications).
Data services are not the same as providing connection to database. There is one very big difference - connection to database will ensure only access and execution permissions but it will not ensure data security. WCF Data Services offer data security because you can create interceptors which will add filters to queries to retrieve only data the user is allowed to see or check if he is allowed to modify the data. That is the difference you can tell your colleague.
In case of abstraction - do you want a quick easy solution or not? You can inject abstraction layer between service and ORM but you need to implement mentioned method and you have to test it.
Most simple approach:
DO NOT PUBLISH YOUR TABLES ;)
Make a separate schema
Add views to this
Put those views to EF and publish them.
The views are decoupled from the tables and thus can be simplified and refactored separately.
Standard approach, also for reporting.
Apart from achieving more granular data authorisation (based of certain field values etc) OData also allows your data to be accessible via open standards like JSON/Xml over Http using OAuth. This is very useful for the web/mobile applications. Now you could create a web service to expose your data but that will warrant a change every time your client needs change in the data requirements (e.g. extra fields needed) whereas OData allows this via OData queries. In a big enterprise this is also useful for designing security at infrastructure level as it will only allow the text based (http) calls which can be inspected/verified for security threats via network firewalls'.
You have some other options for your OData client. Have a look at Simple.OData.Client, described in this article: http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa
And in case you are familiar with Simple.Data microORM, there is an OData adapter for it:
https://github.com/simplefx/Simple.OData/wiki
UPDATE. My recommendations go for client choice while your question is about setting up your server side. Then of course they are not what you are asking. I will leave however my answer so you aware of client alternatives.