Develop Reference

Using Spring Data JPA with an adjacency matrix stored in a MySQL database

I am new to using Spring Data Jpa but I understand one normally creates a 'Model'/ 'Entity' class in Java that represents a row of data in your database table. This makes sense to me when I have a small table with 3 columns/ class attributes, but what about the case of a table with 100 columns? One hardly creates a 'Model' class with 100 attributes? The reason I ask this is because I am storing a large adjacency matrix of train stations in a MySQL database table. I want to interact with this data in my Java Spring application but cannot get my head around how to do this.
I am open to the fact that I may be storing the data incorrectly or should not be using Spring Data JPA at all in this situation. Any advice would be greatly appreciated!
Thanks.
EDIT:
I'll try to explain what I'm trying to do more clearly. I would like to essentially import a copy of this 'Stations' (adjacency matrix) database table into my Java Spring application. I don't know how best to perform this 'import', or what Java data structure to store the table in. I would like to be able to run algorithms like BFS on the data once in Java.
The data in the table is an adjacency matrix showing a graph of a train network. A '1' shows the stations are connected by a track and a '0' shows no connection.

If your model is truly represented with a hundred attributes, then yes, you can create an entity that has a hundred properties. But I think your model needs reworked because the way I look at this, inserting a new record would require a schema change.
Since I don't know what those columns represent, I'm going to assume they're maybe next and previous stations? This would be a simple model to represent this.
#Entity
#Table(name = "station")
#Getter
#Setter
public class Station {
#Id
private Long id;
#Column(name = "name")
private String name;
#OneToOne
#JoinColumn(name = "previous_station_id")
private Station previous;
#OneToOne
#JoinColumn(name = "next_station_id")
private Station next;
}
Your DDL would look like this:
create table station
(
id bigint auto_increment,
name varchar(255) null,
previous_station_id bigint null,
next_station_id bigint null,
constraint station_id_uindex
unique (id),
constraint station_station_id_fk
foreign key (previous_station_id) references station (id),
constraint station_station_id_fk_2
foreign key (next_station_id) references station (id)
);
create index station_next_station_id_index
on station (next_station_id);
create index station_previous_station_id_index
on station (previous_station_id);
alter table station
add primary key (id);
Because this table actually has keys back to itself, you would first insert a station with no previous or next set, then you would update the record to set these values. If I'm off base on what those values are, update your question to better describe what you're trying to model for more accurate answers.

Representing it as a many to many relationship could work well in this case. I'm not very familiar with JPA but I think it would look something like this:
#Getter
#Setter
#Entity
public class Station {
#Id
private Long id;
private String name;
#ManyToMany
private Set<Station> adjacentStations;
}
The stations are interconnected, such that when station B is adjacent to station A (i.e. B is in A's set of adjacent stations), then station A is also adjacent to station B (i.e. A is also in B's set of adjacent stations).
In the database, the relationship between stations would then be represented through a mapping table that has two columns (station_id_1, station_id_2) and one row for each connection.

you can use two classes like this :
#Entity
public class TestClass {
#Id
private long id;
#OneToMany(mappedBy="testClass")
private List<MatrixRow> matrix;
}
and one MatrixLine class:
#Entity
public class MatrixRow {
#Id
private long id;
#ManyToOne
private TestClass testClass;
#CollectionOfElements
private List<Value> row;
}

I think when you're doing BFS you need a previous station name, so either you have to create a model class with 100 names and use the #Getter and #Setter annotation or create a List with 100 elements and store the index representation in some other files as an enum in this case you've to change the database schema to stations and array as blob/text.

Is there a way of using a lookup table as a converter in JPA?

Imagine that I have a simple entity as follows:
#Entity
#Table(name = "PERSON")
public class Person {
#Id
#Column(name = "NAME")
private String name;
#Column(name = "GENDER")
private String gender;
}
And two tables, the actual table holding the information and a lookup table.
TABLE PERSON (
NAME VARCHAR2 NOT NULL,
GENDER INT NOT NULL);
TABLE GENDER_LOOKUP (
GENDER_ID INT NOT NULL,
GENDER_NAME VARCHAR2 NOTNULL);
I want to save the information from my entity into the table, so that the String field gender is automatically converted to the corresponding gender int, using the lookup table as a reference. I thought of two approaches, but I was wondering if there was a more efficient way.
Create an enum and use ordinal enum to persist. I would rather avoid this because I'd like to have only one "source of truth" for the information and for various business reasons, it has to be a lookup table.
Use the #Converter annotation and write a custom converter. I think that this would require me to query the table to pull out the relevant row, so it would mean that I would have to make a JPA call to the database every time something was converted.
I'm currently planning to use 2, but I was wondering if there was any way to do it within the database itself, since I assume using JPA to do all of these operations has a higher cost than if I did everything in the database. Essentially attempt to persist a String gender, and then the database would look at the lookup table and translate it to the correct Id and save it.
I'm specifically using openJpa but hopefully this isn't implementation specific.

Since you seriously considered using enum, it means that GENDER_LOOKUP is static, i.e. the content doesn't change while the program is running.
Because of that, you should use option 2, but have the converter cache/load all the records from GENDER_LOOKUP on the first lookup. That way, you still only have one "source of truth", without the cost of hitting the database on every lookup.
If you need to add a new gender1, you'll just have to restart the app to refresh the cache.
1) These days, who know what new genders will be needed.

JPA - How to use table default value for primary key generation?

I have a table with primary key generation of TO_NUMBER(TO_CHAR(SYSDATE#!,'YYDDD')||LPAD(TO_CHAR(SEQ_REFID.NEXTVAL),11,'0'))
This has been given as default value for the table. When I insert through JDBC, I could leave the column as NULL, so the pk would be generated/defaulted and i'll get the key using getGeneratedKeys() method.
I require similar behavior using JPA. I'm a beginner in JPA. Pl help.
Database used is Oracle 11g.
EDIT: The above mentioned value is not required to be table default. It can be applied from JPA layer if it is possible.
Other Entities depends on this Entity for the pk. PK must be passed over to all child tables.

#Entity
public class Entity {
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
}
Can also be
GenerationType.AUTO
GenerationType.SEQUENCE
GenerationType.TABLE
This reference describes the various strategies

Add the following annotation to the id field:
#Column(insertable = false)
This way, JPA will ignore the field when inserting new values and the database automatically generates the desired key.
However, you shouldn't use such a primary key. It effectively contains 2 different kinds of data in one column which should better be split into two seperate columns.
Make a simple id column with an ascending integer (and absolutely meaning other than "this is entry nr. x"). Then add an additional column with the current timestamp. This timestamp can have a default value and be protected against updates.
This is how it's supposed to be and not only simplifies your queries, but also improves the performance. You can query the table for entries of a specific hour, week and so on, or generate detailed statistics.
Don't try to put multiple information into one column. There's no advantage.

Where did you get the idea that this default PK was a good idea?
If you want the creation time of the row, add a column to your table. Don't embed it in the PK like this.

JPA, do not want insertable=false, updatable=false, workaround?

I am new to both stackoverflow and JPA so I will try to explain this the best i can.
In an entity I want to set the foreign key by giving the int value but also I want to set it by giving an object. Here is some code to explain it better.
#Entity
public class Thread implements Serializable {
#ManyToOne
#JoinColumn(name = "accountId", referencedColumnName = "id", nullable = false)
public Account getAccount() {
return account;
}
#Column(name = "accountId")
#Basic
public int getAccountId() {
return accountId;
}
}
I have tried several ways but the code above is the best example for what I am trying to achieve. I understand that setting insert = false and update = false, in either of the 2 methods, makes this code work as far as compiling and running. But I want to be able to insert the accountId by using an Account object AND by setting the actual int accountId.
The reason for this is because sometimes, in my server, I only have the accountId and sometimes I have the Account object.
I also understand that the best solution is probably to use account.getId() when creating the Thread and setting the accountId. But it would be logically nice in my server to be able to just use the object.
Thanks in advance!

I think you have hit a conceptual problem in your application. You should stick to set the entity and do not use any foreign key values when using JPA. The cause of the problem is that your application is only providing the accountId at some point.
This may be due to different reasons. If this is because the part of the application only providing the accountId is legacy, than I would think it is perfectly fine to have an adapter that converts the accountId into an Account entity and then set that entity. Also not that the adapter could create a JPA proxy so that no actual database access is required at that point. Another reason I can think of, is that the application is loosing information at some point during processing. This may be the case when the application is using the Account in some place and only hands over it's Id to the code in question. Then such code should be refactored to hand over the entity.
In your specific case you are also able to use both, account as entity and the foreign key as attribute with both being insertable and updatable. You just have to make sure, that the accountId attribute value is consistent with the foreign key pointing to the row represented by the account entity. JPA providers should be able to handle this (I know OpenJPA does for example). However you are a bit restricted with this. For example you are only able to read the accountId attribute value, because setting it to a different value would cause an inconsistency between the account entity value.

Do you need to create index on the #id column of a Hibernate table

Do I need to add an index anoatation for the primary key of a hibernate table for decent performance, I assumed that marking a field with #id would mean an index was created
#Id
private String guid;
but I didnt notice anything being created in the ddl that was generated
But if I added an #index annotation
#Id
#org.hibernate.annotations.Index(name = "IDX_GUID")
private String guid;
then I do notice an index being created in the DDL.
So I'm thinking I need to do this for every table, but part of me is thinking is this really neccessary as surely hibernate would want indexes created for the primary key as a starting point ?

You do NOT have to create index explicitly. Instead of seeing DDL statements; I will recommend you to check the final schema created by hibernate. The index is created as part of create table statement.