Working with Hibernate, I noticed that all of the Java objects going into persistence are defined in a mapping file. Is there a way to only depend on the annotations instead of a separate .xml for this? At the time of creation, we do not know what the object that is to be persisted contains. We know it is primitive data types, Strings, ints, floats/doubles, but we do not know how many of each field the object may contain until the same time it needs to have a table created for it to be entered into the db.
Note that Hibernate is just the first ORM solution that I've looked at. I am not tied to it if there is another ORM solution that solves this problem.
I think in your use case, you can use Dozer mapping for managing beans without having explicit definitions of class files and this can ben loaded at runtime using spring annotatons dependency injection.
You may look into JDX ORM for Java. The mapping is defined declaratively in a text file but just a minimal specification is needed for each class - its name and the names of the primary key attributes. Other attributes are automatically picked up by JDX. So you may continue to modify your class without making any further changes to its mapping specification. Disclaimer: I am the architect of JDX ORM.
Related
Let's assume that we have java entities already implemented and annotated with Jpa annotations.
We also have an existing database slightly different to the schema described by said entities.
How I can link the data base with my entities without the code?
Otherwise, how can i proceed from the begining when implementing my entities to make this stuff configurable ( give the user the possiblity of specifying the names of the columns corresponding to the fields of each entity in an externalized configuration file)?
NB: I use hibernate as an ORM.
I believe this is what you are looking for
I'm still new to using ORM stuff in Java, and here is one question I seem to be stuck on:
I have a large number of Hibernate Entities and want to query for them on the server (works fine) then serialise them (using ObjectOuputStream) and send them to a client.
If I deserialize them on the client there is still a large number of Hibernate / javax.persistence dependencies.
Is it possible to transform my entities to POJOs with no dependency on hibernate at all somehow?
Thanks!
EDIT:
To clear thing up, I am using annotations, which is probably silly. I will need to redefine all classes to be annotation-free, then they should be standard POJOs.
Yes, you just have to fall back to XML configuration as opposed to convenient annotations. Hibernate has its hbm files from the very beginning, with JPA you use orm.xml.
Every can be expressed with XML, annotations are only syntactic sugar. This way your entities will be absolutely free of Hibernate/javax.persistence references.
See also: JPA: Should I clean up my entity classes using orm.xml?
P.S.: Keep in mind that serializing your domain model (JPA/Hibernate entities) will prove to be a pain soon once you start refactoring your domain model. Even when you control both sides. Really, really consider DTOs.
In our project we have a constraint of not having the luxury to alter the table structure already in place. The tables are highly denormalized in nature.
We have come up with good POJOs for the application. We have the Entity beans generated out of the exiting tables. Now we have to map the POJOs to the entities so that we can persist.
Ultimately, we combine a good POJO with a bad table. Any thoughts on options/alternatives/suggestions to this approach?
Hibernate/JPA(2) has a rich set of functionality to manipulate the mapping (so that your objects can differ from the tables), so that many (NOT ALL) old tables can be mapped to normal object. -- May you should have a look at this first, any use your pojo/table-"solution" only if this mapping is not powerful enough.
If you have a read only application, you can think of using views to make your table/views more like you objects. This may reduse the amount of strange mapping.
I don't know your mapping, size of the application or use case, but have you considered not to use Hibernate? I ask this, because I can imagine (how I said: I don't know you application), that in a architecture like this, no Hibernate feature is used and so Hibernate will add only a not needed complexity.
If you are using Hibernate you should be able to map your POJOs to the table structure using only XML files, without creating new Java beans. This would allow you to easily change the mapping if all of a sudden you can change the tables structures and make the economy of intermediary beans. That's the best you can do.
I'm extending the data model of an Java application to include some kind of a setting facility. Settings in this application would basically be Strings or Numbers, no entities or other model objects.
My Question is what's the best way to map this requirement to JPA (Hibernate)?
I first thought about implementing a Setting class with properties for each desired type but maybe there is a way to use something like Hibernate's Any mapping? The Problem with the any mapping seems to be that it is meant to express relations to entities not embeddables.
Any ideas?
edit:
To clarify the requirement. I want to persist variable data in a simple way, think about C style union or a bean property of the Object type.
Does JPA support a kind of “Any” mapping for embeddable objects?
To my knowledge, neither JPA nor Hibernate do support defining relation to embeddable which are not entities. Just in case, the JPA wikibook has a very interesting section on embeddables.
If I misunderstood your question, please clarify (again), your goal is still not clear (at least for me). Maybe a "pseudo" example could help.
I've been using JPA on a small application I've been working on. I now have a need to create a data structure that basically extends or encapsulates a graph data structure object. The graph will need to be persisted to the database.
For persistable objects I write myself, it is very easy to extend them and have the extending classes also persist easily. However, I now find myself wanting to use a library of graph related objects (Nodes, edges, simple graphs, directed graphs, etc) in the JGrahpT library. However, the base classes are not defined as persistable JPA objects, so I'm not sure how to get those classes to save into the database.
I have a couple ideas and I'd like some feedback.
Option 1)
Use the decorator design pattern as I go along to add persistence to an extended version of the base class.
Challenges:
-- How do I persist the private fields of a class that are needed for it to be in the correct state? Do I just extend the class add an ID field, and mark it as persistable? How will JPA get the necessary fields from the parent class? (Something like ruby's runtime class modification would be awesome here)
-- There is a class hierarchy (Abstract Graph, Directed Graph, Directed Weighted Graph, etc.). If I extend to get persistence, extending classes still won't have the common parent class. How do I resolve this? (Again, Something like ruby's runtime class modification would be awesome here)
Option 2) Copy paste the entire code base. Modify the source code of each file to make it JPA compatible.
-- obviously this is a lot of work
I'm sure there are other options.. What have you got for me SO???
Do the base classes follow the JavaBeans naming conventions? If so you should be able to map them using the XML syntax of JPA.
This is documented in Chapter 10 of the specification:
The XML descriptor is intended to
serve as both an alternative to and an
overriding mechanism for Java language
metadata annotations.
This XML file is usually called orm.xml. The schema is available online
Your options with JPA annotations seem pretty limited if you're working with a pre-existing library. One alternative would be to use something like Hibernate XML mapping files instead of JPA. You can declare your mappings outside of the classes themselves. Private fields aren't an issue, Hibernate will ignore access modifiers via reflection. However, even this may end up being more trouble than its worth depending on the internal logic of the code (Hibernate's use of special collections and proxies for instance, will get you in hot water if the classes directly access some of their properties instead of using getter methods internally).
On the other hand, I don't see why you'd consider option 2 'a lot of work'. Creating a ORM mapping isn't really a no brainer task no matter how you go about it, and personally I'd consider option 2 probably the least effort approach. You'd probably want to maintain it as a patch file so you could keep up with updates to the library, rather than just forking.