We Keep Coding

Spring data jpa - field that has all the possible values of a table

Using Spring Boot and Spring Data JPA, I have a table which represents an enum value, and a corresponding entity that I want that one of its field will be 'all the possible values the enum can have', i.e. a field possibleValues that will be a select all on the other table. Preferably I don't want to have a relationship like #ManyToMany since:
It will always be a select all, I don't want to save to the database all the options and update them each time the enum values table changes.
I am going to have several enums, so for each enum create another many-to-many is less than ideal.
I've tried to find something like #Formula that will let me select all the values from another table, but it doesn't seem to work:
#Transient
#Formula("select e.name from EnumTable e")
private List<String> possibleValues;
results in possibleValues always being null, and if I remove the #Transient I have to define the relationship between the two entities.

For Enum value in database, I recommend using string (for object, you can use JSON to convert first before store and covert back after retrieve )

How to prevent Spring Data MongoDB from mapping id field as object id?

I have set up my own mechanism for assigning identities to my domain objects, and so when persisting them, there really isn't much value for me to keep track of what MongoDB assigns to them. However, I name the identity fields for my domain classes id because, well, it's concise and understandable. The problem is that, according to the documentation, Spring will automatically map this field to MongoDB's assigned ObjectID. How do I prevent this from happening without having to rename my id field, or defining a custom identity field annotated with #Id just for the sake of working around this?

Use #MongoId instead of #Id
#MongoId(targetType = FieldType.STRING)
protected String id;
It will store String even if the "shape" is an ObjectId

Well, you can't do that with Spring data I am afraid. Mongodb (and in turn, Spring data) needs a field to uniquely identify each document. If you have an id field already, and if it's unique for each and every object then yes, you can annotate it with #Id and mongo will take care of the rest.
If not, you will have to create a new field and map it to _id.

Hibernate - update an object (entity) in DB, based on "not complete" object, without loosing values, for already filled columns

I wanted to update object in Hibernate, which let say has 3 fields, already filled in (id=1, firstname="kim", lastname="kardashian"), based on some "delta" object (id=1, firstname="kimirsen", lastname=null).
I'm using:
Session.update(object);
and my Object entity class has below annotation:
#DynamicUpdate
that I've found it's required.
However I'm still getting:
NULL not allowed for column "LASTNAME"; SQL statement:
exception.
Is there any way, to update object, without checking each and every fields (if it's null, if yes, then query field in DB to check, if it's already filled in or not...)?

if you want to update only the firstname, then you should query the DB and get the object with id, and modify the firstname, before calling the update.
I don't think you can leave out lastname, and expect Hibernate to ignore it.
DynamicUpdate is for specifying whether Hibernate should update in the DB, all the fields of the Persitent Object or only the modified fields (in comparison to the db).

How to inject custom object ids into JPA entities

I am using JPA 2 for an enterprise application, and my DBA's just hit me with a twist.
They want me to use the group's centralized object ID generator for all my tables. This means rather than using table values or a sequence table, I will need to call a web service to get a batch of ~50 ids.
Then, as I persist any new object, I would need to inject this id first, and save that to the table.
So how would I manipulate the #Id column of an entity to handle this.
Is it as simple as setting a key before I persist? I suspect that would throw some sort of unmanaged entity with ID set error.

Update:
The better method is to actually specify a Sequence strategy on Generated fields and specify a custom Sequence class.
JPA will then call this class's nextId() method every time it inserts a new object.
This method allows full graphs to be persisted without intervening on each entity manually.
Figured it out. Amazingly complex ;) - just remove the GeneratedValue annotation from the key field.
It is intended for Native Ids like SSN or email, but works regardless of source.
#Entity
public class Client{
#Id
#Column(name="CLNT_ID")
private long key;
#Column(name="CLNT_NUM")
private String clientNumber;
...
}

The difference between annotating fields and methods in JPA (Hibernate)?

Are there any statements in JPA spec or official docs about certain JPA implementations which describe the behavior when we annotate entity's methods and when we annotate entity's fields?
Just a few hours ago I met an ugly problem: I use JPA (via Hibernate, but without anything Hybernate-specific in java code) with MS SQL Server. And I put all annotations on entities' fields (I preferred this style until this day).
When I looked at the DB I found that all table columns which should be foreing keys and which should contain some integers (ids) in fact had varbinary(255, null) type and contained hashes of something (I don't know what was that but it looked as a typical MD5 hash).
The most frustrated thing is that the app worked correctly. But occasionally (on updates) I got MS SQL exception which stated that I tried to insert too long values and data cannot be truncated.
Eventually (as an experiment) I removed all annotations from entities fields and put all of them on methods. I recreated DB and all tables contained perfect FK column. And those columns stored integers (ids, like 1, 3 ,4 ...).
So, can somebody explain what was that?
I've found this SO thread and it's accepted answer says that the preferred way is to put annotations on fields. At least for my concrete case I can say that it's not true.

JPA allows for two types of access to the data of a persistent class. Field access which means that it maps the instance variables (fields) to columns in the database and Property access which means that is uses the getters to determine the property names that will be mapped to the db. What access type it will be used is decided by where you put the #Id annotation (on the id field or the getId() method).

From experience, I do the following.
I put the entity details at the top of the entity class definition, (schema, row constraints, etc) for instance....
#Entity
#Table(name="MY_TABLE", schema = "MY_SCHEMA", uniqueConstraints = #UniqueConstraint(columnNames = "CONSTRAINT1"))
For the fields defined, I do not put the annotations on the field declarations, but rather on the getter methods for those fields
#Column(name = "MY_COL", table="MY_TABLE", nullable = false, length = 35)
public String getMyCol() {
return this.myCol;
}
public void setMyCol(String myCol) {
this.myCol = myCol;
}