Datastax Cassandra java driver - Object mapper - Auto create tables - java

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).

Related

Obtain copy of existing object with Hibernate and Spring Boot

I have the following tricky situation in my Spring Boot application that uses Hibernate. I load objects from the data store and I modified them in several functions of my application that are not related one with another. The idea is that I need to load the existing copy of the object from the database before saving its update instance in order to create a backup, but if I use the repository's findById method, Hibernate finds a copy of the object (the modified one) in its cache and returns that one and it is not ok for me, because I need a copy of the original object, before it was modified (the object that is currently in the database). I tried using a separate Session, but in case of multiple objects the DB is locked and I'm not able to access the database anymore (MS Sql Express). Has anyone an idea on how to obtain the original unmodified object before persisting tghe changes in the database ? Thanks
To keep backup of entities you should use #Audited (it keeps versions / snaphshots of each entity).
You can have a look over there https://www.baeldung.com/database-auditing-jpa
A more advanced approach is https://javers.org/.
Javers is the state-of-the-art way to do what you want to do. I think it will suit your needs.

How to persist JavaFX properties in SQLite using ORMLite?

I am using JavaFX to create an app and I need (it would be very cool) to persist JavaFX properties such as SimpleStringProperty or SimpleObjectProperty.
I've seen this issue (now closed) that make use of the SimpleStringPropertyPersister class.
But, I don't actually have this class.
I've tried using the SerializablePersister class as my persister class, and ORMLite didn't send me a huge error. But I'm not sure that all JavaFX properties (at least the ones that I want to use) are Serializable, as in the javadoc it is not.
I'm using the last version available at the maven central :
<dependency>
<groupId>com.j256.ormlite</groupId>
<artifactId>ormlite-jdbc</artifactId>
<version>5.1</version>
</dependency>
How can I achieve this ?
I am using JavaFX to create an app and I need (it would be very cool) to persist JavaFX properties such as SimpleStringProperty or SimpleObjectProperty.
The first link in a search on google for "ormlite custom persister" brought me to the documentation for customer persisters. Shocking. I spent a lot of time on the ORMLite docs so they should be helpful. There also is source code example of a custom date persister.
To quote from the docs:
When defining a data persister class from scratch, you could extend one of the other data type persisters or the BaseDataType class. You will need to define the following methods.
parseDefaultString – Converts a default string into a SQL argument suitable to be loaded into the database.
resultToSqlArg – Uses the DatabaseResults object to get the right SQL argument type out of the results.
sqlArgToJava – Converts the SQL argument to the associated Java class.

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.

Using morphia’s fromDBObject without DataStore

I am working on an application that directly uses Java MongoDB driver for Mongo queries.
I’d like to use Morphia to map retrieved Documents to my POJOs and vice versa (but I do not want to do queries through Morphia itself).
I am trying to achieve this with Morphia 1.1, however the fromDBObject in this version requires Morphia’s DataStore as an argument (previous versions did without it) – and I do not want to give Morphia actual connection to the database. I am not using references to join data from different collections – so when transforming an already retrieved document to POJO it is not needed to retrieve any additional data from the DB.
Can I achieve this in the version 1.1 (eg. by creating and passing an empty, nonfunctional datastore (how to create it?), or just by passing null)?
If not, I can live with the older (1.0.1) version – but does that make sense?
And if not – what would be the best solution for mapping POJOs to Mongo documents – are there any other, currently maintained, libraries to achieve this?
And, again, if not – what would be the best way to implement this functionality myself? The solution should be as generic as possible regarding document and POJO classes schema, I am OK with annotating my entity classes.
Did you try passing in null for the Datastore? It's used for resolving any #Referenced fields for the most part. You should be fine just passing null. But as always, "try it and see."

Making sure that the same object isn't loaded twice from XML API in Java

I am new to Java, and am working on a Public Transit Java app as a first small project.
I am loading transit data in from a server through an XML api (using the DOM XML API). So when you call a constructor for say a BusStop(int id), then the constructor loads the info about that Stop from the server based on the id provided. So, I am wondering about a couple things: how can I make sure I don't instantiate two BusStop objects with the same id (I just want one object for each BusStop)?
Also does anyone have recommendations on how I should load up the objects, so I don't need to load the whole database every time I run the app, just the BusStop, and relevant Arrivals and BusTrips objects for that stop? I have done C++ and MVC PHP programming previously, but haven't had experienced loading large numbers of objects with circular object references etc.
Thanks!
I wouldn't start the download/deserialization proces in a constructor. I would write a manager class per entity type with a method to fetch a Java object for a given entity based on its ID. Use a HashMap with the key type as your entity ID and the value type as the Java class for that object. The manager would be a singleton using your preferred pattern (I would probably use static members for simplicity).
The first thing the fetch method should do is check the map to see if it contains an entry for the given ID. If it has already fetched and build this object, return it. If it has not, fetch the entity from the remote service, deserialize the object appropriately, load it into the HashMap by the specified ID, and return it.
Regarding references to other object I suggest you represent those as IDs in your Java objects rather than storing them as Java object references and deserializing them at the same time as the referencing object. The application can lazily instantiate those objects on demand through the relevant manager. This reduces problems through circular references.
If the amount of data is likely to exceed available RAM on your JVM you'd need to consider periodically removing older objects from the map to recover memory (confident they would be reloaded when required).
For this application I would use the following Java EE technologies: JAX-RS, JPA and JAXB. You will find these technologies included in almost every Java application server (i.e. GlassFish).
JPA - Java Persistence API
Provides a simple means of converting your objects to/from the database. Through annotations you can mark a relationship as lazy to prevent the entire database from being read. Also through the use of caching database access and object creation is reduced.
JAXB - Java Architecture for XML Binding
Provides a simple means of converting your objects to/from XML. An implementation is included in Java SE 6.
JAX-RS - Java API for RESTful Services
Provides a simple API (over HTTP) for interacting with XML.
Example
You can check out an example I posted to my blog:
Part 1 - The Database
Part 2 - Mapping the Database to JPA Entities
Part 3 - Mapping JPA entities to XML (using JAXB)
Part 4 - The RESTful Service
Part 5 - The Client
For the classes you want to load only once per given id, use some kind of Factory design pattern. Internally you may want to store id to instance mapping in a Map. Before actually fetching the data from server, first do a lookup on this map to see if you already have a class loaded for this id. If not then go ahead with fetching and the update the map.

Categories