I am in the process of troubleshooting a recent translation of EJB code to native Hibernate code (painful process, since EJB spoiled me so much with its convenience).
One thing I find troublesome is that Hibernate keeps its entity declarations in a hbm.xml file and then the configurations in separate files. While this isn't necessarily a big issue, the Netbeans wizard doesn't really let the developer to just click a button, detect, all the entities on the fly, and update the configuration file.
With persistence.xml, however, I can do that easily by just adding the classes and forget about it. Another good thing is that persistence.xml stores pretty much everything needed for the ORM aside from the class-specific annotations (which I am keeping).
With that said, is there any way for me to have Hibernate to (1) stay off EE and (2) use persistence.xml to get the connection, mapping, etc?
Also, a related question - CriteriaQuery is apparently a Java EE thing. One thing I really like about using EJB is that there are strong compile-time contraints. For instance, I can put ClassName_.myAttribute directly as a parameter in a CriteriaQuery, whereas if I use the Hibernate native "Criteria" object, I have to use "my_attribute" instead, which is not subjected to compile time integrity checks (Note: ClassName_.myAttribute maps to "my_attribute" on the table).
So is there anyway to keep that compile-time integrity?
Thanks.
Hibernate EntityManager can be used outside of a Java EE container. See http://docs.jboss.org/hibernate/core/4.0/hem/en-US/html_single/#architecture-javase.
Moreover, even with the Hibernate native API, since you're using annotations, you don't need any hbm.xml file. Just a central Hibernate config file listing the entities and some Hibernate properties.
Related
I'm working on a new project, using concepts like clean architecture, protecting my model and business rules from external dependencies and frameworks. Also, I prefer not to use traditional ORM libraries (like JPA/Hibernate) and have choose to use plain jdbc (through spring jdbctemplate).
It was going pretty well, but I'm getting tired of write 20x almost the same query for all my domain classes on a basic crud reposity. So, I take a look at Spring Data JDBC, but it appears that it's necessary to add annotations on my domain classes to make it work properly. I really don't want to do that, first because I want to make my domain cleaner as possible from any dependencies, and second because this is one of the (many) things I really dislike on JPA.
I was wondering that, the repository needs only 2 things: a rowmapper definition and the PK definition (and both could be defined at the repository itself) avoiding the complete use of annotations.
So, my question is there any way to use Spring Data JDBC without annotations?
No, there is no easy way to use Spring Data JDBC (https://spring.io/projects/spring-data-jdbc).
What you could do is to replace those classes that do the annotation interpretation (RelationalPersistentEntityImpl, and BasicRelationalPersistentProperty) and replace them with something that gets the information from elsewhere.
There is a different framework wich might fit the bill which is also named Spring Data JDBC 🤷♀️ https://github.com/nurkiewicz/spring-data-jdbc-repository
It seems pretty close to what you are looking for but it has its last commit 6 years ago and is archived on Github.
I'm working on a new project, using concepts like clean architecture, protecting my model and business rules from external dependencies and frameworks. Also, I prefer not to use traditional ORM libraries (like JPA/Hibernate) and have choose to use plain jdbc (through spring jdbctemplate).
It was going pretty well, but I'm getting tired of write 20x almost the same query for all my domain classes on a basic crud reposity. So, I take a look at Spring Data JDBC, but it appears that it's necessary to add annotations on my domain classes to make it work properly. I really don't want to do that, first because I want to make my domain cleaner as possible from any dependencies, and second because this is one of the (many) things I really dislike on JPA.
I was wondering that, the repository needs only 2 things: a rowmapper definition and the PK definition (and both could be defined at the repository itself) avoiding the complete use of annotations.
So, my question is there any way to use Spring Data JDBC without annotations?
No, there is no easy way to use Spring Data JDBC (https://spring.io/projects/spring-data-jdbc).
What you could do is to replace those classes that do the annotation interpretation (RelationalPersistentEntityImpl, and BasicRelationalPersistentProperty) and replace them with something that gets the information from elsewhere.
There is a different framework wich might fit the bill which is also named Spring Data JDBC 🤷♀️ https://github.com/nurkiewicz/spring-data-jdbc-repository
It seems pretty close to what you are looking for but it has its last commit 6 years ago and is archived on Github.
I'd like to automatically generate Hibernate mappings for some Java classes I have. Basically, I'd like all objects in the class to have the equivalent of the #OneToOne annotation, and all collections to have the equivalent of the #OneToMany annotation by default. I'd like to be able to fine-tune this later, but 99% of my data works this way, and it would take a very long time to go through all the classes and add the annotations manually.
Is this possible?
edit: Sorry, I think omitted something very important: I'd actually like to generate these default annotations from classes, not from a database. I would still have to design about 40 tables if I were to start with the database, but I already have a package containing all those classes. Is it possible to generate the proper mappings based on existing Java classes?
Yes, in eclipse there is a plugin called hibernate tools from jboss, which can generate mapping from a existing database.
You can generate all hibernate files both xml and annotations variant.
Just Google Hibernate Tools to know how to use it.
Thanks !!
If you are creating new classes then you can create the database structure first and then create classes using database. In eclipse, hibernate provides Hibernate code generation feature. You can use that.
I'm currently working on a desktop application using JPA/Hibernate to persist data in a H2 database. I'm curious what my options are if I need to make changes to the database schema in the future for some reason. Maybe I'll have to introduce new entities, remove them or just change the types of properties in an entity.
Is there support in JPA/Hibernate to do this?
Would I have to manually script a solution?
I usually let Hibernate generate the DDL during development and then create a manual SQL migration script when deploying to the test server (which I later use for UAT and live servers as well).
The DDL generation in Hibernate does not offer support for data migration at all, if you only do as much as adding a non-null field, DDL generation cannot help you.
I have yet to find any truely useful migration abstraction to help with this.
There are a number of libraries (have a look at this SO question for examples), but when you're doing something like splitting an existing entity into a hierarchy using joined inheritance, you're always back to plain SQL.
Maybe I'll have to introduce new entities, remove them or just change the types of properties in an entity.
I don't have any experience with it but Liquibase provides some Hibernate Integration and can compare your mappings against a database and generate the appropriate change log:
The LiquiBase-Hibernate integration records the database changes required by your current Hibernate mapping to a change log file which you can then inspect and modify as needed before executing.
Still looking for an opportunity to play with it and find some answers to my pending questions:
does it work when using annotations?
does it require an hibernate.cfg.xml file (although this wouldn't be a big impediment)?
Update: Ok, both questions are covered by Nathan Voxland in this response and the answers are:
yes it works when using annotations
yes it requires an hibernate.cfg.xml (for now)
There are two options:
db-to-hibernate - mirror DB changes to your entities manually. This means your DB is "leading"
hibernate-to-db - either use hibernate.hbm2ddl.auto=update, or manually change the DB after changing your entity - here your object model is "leading"
IDEs like Netbeans allow generation of entity classes through a persistence context. If you had access to underlying generation method (not sure if it is an external tool or part of the IDE), could you generate database entity classes dynamically at runtime? The idea being that you could hook into the entity classes using reflection.
I know you can go the other way and generate the database from the entity class, however due to permissions issues in my work environment that would be a no go. However, if you reverse the process and pull the classes from the database it may be feasible in my environment. The idea being that the database would serve as a single point of configuration/control.
It's theoretically possible but what would be the point? Java is statically typed so you would only be able to use the generated classes by reflection and you would have no way of giving them behaviour, so removing the whole point of object-relational mapping. Loading the data into Maps or just using SQL record sets would be more convenient.
If you have an existing schema you can write classes that act in the way your application needs and declaratively map them onto the schema. That way the code is the simplest expression of your application logic and is persistence-agnostic.
You can find on JBoss website a tool to do the reverse engineering from database to java objects.
The source code is available, you should dig in!
https://www.jboss.org/tools/download/stable.html
Assuming you're using Hibernate, you might be able to use Hibernate Tools to generate the database schema. Although primarily designed for Eclipse and Ant, its theoretically possible to link it in and invoke it like any other JAR.