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.
Related
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."
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).
I thought I knew everything about UDTs and JDBC until someone on SO pointed out some details of the Javadoc of java.sql.SQLInput and java.sql.SQLData JavaDoc to me. The essence of that hint was (from SQLInput):
An input stream that contains a stream
of values representing an instance of
an SQL structured type or an SQL
distinct type. This interface, used
only for custom mapping, is used by
the driver behind the scenes, and a
programmer never directly invokes
SQLInput methods.
This is quite the opposite of what I am used to do (which is also used and stable in productive systems, when used with the Oracle JDBC driver): Implement SQLData and provide this implementation in a custom mapping to
ResultSet.getObject(int index, Map mapping)
The JDBC driver will then call-back on my custom type using the
SQLData.readSQL(SQLInput stream, String typeName)
method. I implement this method and read each field from the SQLInput stream. In the end, getObject() will return a correctly initialised instance of my SQLData implementation holding all data from the UDT.
To me, this seems like the perfect way to implement such a custom mapping. Good reasons for going this way:
I can use the standard API, instead of using vendor-specific classes such as oracle.sql.STRUCT, etc.
I can generate source code from my UDTs, with appropriate getters/setters and other properties
My questions:
What do you think about my approach, implementing SQLData? Is it viable, even if the Javadoc states otherwise?
What other ways of reading UDT's in Java do you know of? E.g. what does Spring do? what does Hibernate do? What does JPA do? What do you do?
Addendum:
UDT support and integration with stored procedures is one of the major features of jOOQ. jOOQ aims at hiding the more complex "JDBC facts" from client code, without hiding the underlying database architecture. If you have similar questions like the above, jOOQ might provide an answer to you.
The advantage of configuring the driver so that it works behind the scenes is that the programmer does not need to pass the type map into ResultSet.getObject(...) and therefore has one less detail to remember (most of the time). The driver can also be configured at runtime using properties to define the mappings, so the application code can be kept independent of the details of the SQL type to object mappings. If the application could support several different databases, this allows different mappings to be supported for each database.
Your method is viable, its main characteristic is that the application code uses explicit type mappings.
In the behind the scenes approach the ResultSet.getObject(int) method will use the type mappings defined on the connection rather than those passed by the application code in ResultSet.getObject(int index, Map mapping). Otherwise the approaches are the same.
Other Approaches
I have seen another approach used with JBoss 4 based on these classes:
org.jboss.ejb.plugins.cmp.jdbc.JDBCParameterSetter
org.jboss.ejb.plugins.cmp.jdbc.JDBCResultSetReader.AbstractResultSetReader
The idea is the same but the implementation is non-standard (it probably pre-dates the version of the JDBC standard defining SQLData/SQLInput).
What other ways of reading UDT's in Java do you know of? E.g. what does Spring do? what does Hibernate do? What does JPA do? What do you do?
An example of how something similar to this can be done in Hibernate/JPA is shown in this answer to another question:
Java Enums, JPA and Postgres enums - How do I make them work together?
I know what Spring does: you write implementations of their RowMapper interface. I've never used SQLData with Spring. Your post was the first time I'd ever heard of or thought about that interface.
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.
I'm developing (another) java web framework for personal use, and in addition to that I also want to develop somekind of persistence framework.
I have already developed and engine that in order to access the table, you must only extend a class and create your fields with the same type and name of those in the table. Ex:
private int id;
private String nome;
So you only need now to build the query and execute. The engine put the values on the right fields.
Recently I've had a quite good experience with Django, wich in order to update, create and filter the table you just need to call .save(), .create(field1=field, field2=213) and, .filter(filterfield=value).
I want to build this to, but I am having some trouble, because the extending class would actually have to write more, fact that I don't want to force. I have had the idea to the extending class write an enum implementing an Interface. So the super class get those fields, along with a private HashMap (the key is the enum) and keep the values, so the client just calls:
String nome = Usuarios.get(Usuarios.fields.name);
To retrieve the value.
Usuarios.update(new Pair(Usuarios.fields.name, "José Leal"), new Pair(Usuarios.fields.sobrenome, "Domingues"));
To update and so on.
Anyone have a better idea? I also use velocity framework, so I would like my field to be accessible by its getter.
ps: I know the existence of hibernate and etc.
I would suggest that you not force users to extend one of your own classes for their model objects. This locks them out of extending their own classes, and makes them more vulnerable to API changes you might make later.
Seeing as javax.persistence already defines annotations that can be used for mapping properties to a database, I'd suggest instead that you let the users make POJOs for their model objects with annotated properties. That way, along with the other mentioned benefits, you're following an already established standard and thereby lowering the barrier to entry for your users.