We Keep Coding

How to map custom data structures to bean entities with JPA/Hibernate?

We have a (possibly large) custom data structure implemented in Java (8+). It has a simple and optimal API for querying pieces of data. The logical structure is roughly similar to an RDMS (it has e. g. relations, columns, primary keys, and foreign keys), but there is no SQL driver.
The main goal is to access the data via ORM (mapping logical entities to JPA annotated beans). It would be nice if we could use JPQL. Hibernate is preferred but other alternatives are welcome too.
What is the simplest way to achieve this? Which are the key parts of such an implementation?
(P. S. Directly implementing SessionImplementor, EntityManagerImplementor etc. seems to be too complicated.)

You have two possibilities.
Implement a JDBC compliant driver for your system, so you can use a JPA implementation such as Hibernate "directly" (although you may need to create a custom dialect for your system).
Program directly against the JPA specification like ObjectDB does, which bypasses the need to go through SQL and JPA implementations completely.
The latter one is probably easier, but you'd still need to implement the full JPA API. If it's a custom in-house-only system, there's very little sense in doing either one.

One idea I thought up just now, that I feel may work is this:
Use an existing database implementation like H2 and use the JPA integration with that. H2 already has a JPA integration libraries, so it should be easy.
In this database, create a Java stored procedure or function and call it from your current application through JPA. See this H2 documentation on how to create a Java stored procedure or function. (You may want to explore the section "Using a Function as a Table" also.)
Define a protocol for the service methods and encapsulate it in a model class. An instance of this model class may be passed to the function/SP and responses retrieved.
Caveat: I have never done this myself but I think it will work.
Edit: Here is a diagram representing the thought. Though the diagram show H2 separately, it will most probably be in the same JVM as "Your Java/JEE application". However, since it is not necessary to use H2, I have shown it as as separate entity.

Create Table from generated classes

I have generated the representations for my database-model in jooq.
Can I use this to recreate the Database?.
createTable(org.jooq.Table<?> table) wants me to specify the columns.
Ideally when the schema changes, i would just update the jooq representation and when another user installs it it would automatically create the right schema.

There is a pending feature request for this kind of functionality:
https://github.com/jOOQ/jOOQ/issues/3160
But as of jOOQ 3.7, this isn't yet possible. The main challenge is the fact that the generated schema meta information will always lack important pieces (e.g. vendor-specific storage clauses), so this kind of functionality is good for simple databases or test databases at best.

Datastax Cassandra java driver - Object mapper - Auto create tables

The actual use case i'm working on has many classes that should be persisted (basically different sensor types). Currently i have to create the table per hand for every sensor type. Isn't there a mechanism of the driver that could auto create the respective tables if they are not existent (like seen in e.g. Hibernate)?
This would allow me to deploy the app on other systems without need for recreating the tables again. Furthermore this is quite handy for quick prototyping ;)

I created a partial solution to the problem - a table / udt create-query creation facility. It can be found here:
https://gist.github.com/eintopf/3ae360110846cb80a227
Unfourtunately the type mapping is NOT complete at the moment, since the respective type mapper class in the object mapper package of datastax is private.
The program just builds all CREATE queries and one use them like he wants (copy paste into cqlsh or use it directly on the cassandra session via Java).

Not at the moment, but this is a planned feature (JAVA-569).

Is embedded id the right way to move to mongo from jpa

We have a number of object that have an id of type Long and are stored in MySql and use JPA/Hibernate for ORM. We are going to move some to Mongo in the future. Is it sensible to create an embeddable class for the Id field, e.g. ContentId and use this throughout the system in place of Long so that when we move to MongoDB or anothe noSql database without Long ids that we only have to change the internal representation of the ContentId class. I can only find references to using #EmbeddedId for composite keys. Is this a sensible thing to do? I don't want to have to go through all the code in a year or so when we change and replace Long with ObjectId.

MongoDB uses a generated OID as the default Id. You can also define your own using the _id attribute. The OID is basically a UUID, which maps best to a String. I would just use a UUID in MySQL, so you can use the same model on either. MongoDB does not support a composite id, so using a composite id is probably not a good idea.
EclipseLink supports JPA on both MySQL and MongoDB. EclipseLink also supports a #UuidGenerator that works with any database.
http://java-persistence-performance.blogspot.com/2012/04/eclipselink-jpa-supports-mongodb.html
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/NoSQL

I don't see what EmbeddedId would give you to gain portability .... best to focus on the value generators available and what the datastore would support, and look for how you can have something mappable on both datastores to ease the migration.
DataNucleus JPA obviously supports persistence to MongoDB and has for some time, allowing the full range of identities, whether it is the native MongoDB UUID ("identity" in JPA parlance), String-based (uuid, uuid-hex) or numeric ("table"). This gives portability and you can choose what suits your model best. It also supports persistence to many other types of datastores (RDBMS, Excel, ODF, ODBMS, HBase, AppEngine, LDAP, and others) should you need portability to other datastores too.

Creating tables dynamically in Hibernate environment

There's an enterprise application using Java + Hibernate + PostgreSQL. Hibernate is configured via annotations in the Java source code. So far the database schema is fixed, but I faced the problem that it needs to be dynamic:I can receive data from different locations and I have to store these in different tables. This means that I have to create tables run-time.
Fortunately, it seems that all of these data coming from the different institutes can have the same schema. But I still don't know how to do that using Hibernate. There are two main problems:
How to tell to Hibernate that many different tables have the same structure? For example the "Patient" class can be mapped to not just the "patient" table, but the "patient_mayo_clinic" table, "patient_northwestern" table, etc. I can feel that this causes ambiguity: how Hibernate knows which table to access when I do operations on the Patient class? It can be any (but only one) of the former listed tables.
How can I dynamically create tables with Hibernate and bind a class to them?
Response to suggestions:
Thanks for all of the suggestions. So far all of the answers discouraged the dynamic creation of tables. I'll mark Axel's answer, since it achieves certain goals, and it is a supported solution. More specifically it's called multi-tenancy. Sometimes it's important to know some important phrases which describes our problem (or part of our problem).
Here are some links about multi-tenancy:
Multi-tenancy in Hibernate
Hibernate Chapter 16. Multi-tenancy
Multi-tenancy Design
EclipseLink JPA multi-tenancy
In real world scenario multi-tenancy also involves the area of isolating the sets of data from each other (also in terms of access and authorization by different credentials) once they are shoved into one table.

You can't do this with Hibernate.
Why not extend your patient table with an institute column?
This way you'll be able to differentiate, without running into mapping issues.

I am afraid you can't do this easily in Hibernate. You would have to generate the Java source, compile it, add it to your classpath and load it dynamically with java.reflection package. If that works, which I doubt it, it will be an ugly solution (IMHO).
Have you consider using a schema less database i.e: NoSQL databases or RDF
databases. They are much more flexible in terms of what you can store in them , basically things are not tight up against a relational schema.

In most environments it is not a good idea to create tables dynamically simply because dbas will not give you the rights to create tables in production.
Axel's answer may be right for you. Also look into Inheritance Mapping for Hibernate.

I agree that its not advisable to create tables dynamically nevertheless it's doable.
Personally i would do as Axel Fontaine proposed but if dynamic tables is a must-have for you I would consider using Partitioning.
PostgreSQL allows you to create ona main table and few child tables (partitions), records are disjunctive between child tables, but every record from any child table is visible in parent table. This means that you can insert rows into any child table you want using just simple insert statement (its not cool but has the same level of complexity as composing and persisting an entity, so its acceptable in your case) and query database using HQL