I'm using the createSQL() method in Hibernate to make an insert operation in my database.
What I want to do is declraing a custom SQL statement so that I can apply a MD5() function to a field on a table. That's why I can't just simply use the save(Object) method.
I got a warning from Eclipse IDE that says:
The method createSQLQuery(String) from the type QueryProducer is deprecated.
Despite of this the insert operation is performing as expected.
The current version of Hibernate I'm using on my project is 5.2.5.Final.
So, the question would be: is there another way to achieve the same in this version of Hibernate in order to get rid of that annoying warning?
I also know adding #SuppressWarnings("deprecation") annotation will solve the issue, but I'm not pretty sure whether it will cause any problems in the future.
It's worth mentioning that I'm a begginer using this framework.
The javadoc of the deprecated QueryProducer.createSQL(String) describes what to use instead:
Deprecated. (since 5.2) use createNativeQuery(String) instead
Create a NativeQuery instance for the given SQL query string.
Just adding #SuppressWarnings("deprecation") is usually no good idea,
because you may get problems in the future; i.e. when you move to a newer Hibernate version where the now deprecated method then will have been removed.
Related
There may be some related questions, but I think my situation is peculiar enough to justify a question on its own.
I'm working on a historically grown huge Java project (far over one million LOC, due to other reasons we're still bound to Java 6 at the moment), where reflection is used to display data in tables - reflection is not used for dynamically changing the displayed data, but just for using some kind of short cuts in the code. A simplified part of the code looks like this.
TableColumns taco = new TableColumns(Bean.class);
taco.add(new TableColumn("myFirstMember"));
taco.add(new TableColumn("mySecondMember"));
...
List<Bean> dataList = getDataFromDB(myFilterSettings);
taco.displayTable(dataList);
So the values of the table cells of each row are stored in an instance of Bean. The values for the first cell comes from calling itemOfDataList.getMyFirstMember() (so here comes the reflection part of the code). The rendering of the table cells is done depending on the return type of the itemOfDataList.getMyFirstMember().
This way, it's easy to add new columns to the table, getting them rendered in a standard way without caring about any details.
Problem of this approach: when the getter name changes, the compiler doesn't notice and there will be an exception at runtime in case Bean.getMyFirstMember() was renamed to Bean.getMyFirstMemberChanged().
While reflection is used to determine which getter is called, the needed info is in fact available at compile time, there are no variables used for the column info.
My goal: having a validator that will check at compile time whether the needed getter methods in the Bean class do exist.
Possible solultions:
modifying the code (using more specific infos, writing an adapter, using annotations or whatever that can be checked at compile time by the compiler), I explicitely don't want a solution of this kind, due to the huge code basis. I just need to guarantee that the reflection won't fail at runtime.
writing a custom validator: I guess this shouldn't be too complex, but I have no real idea how to start, we use eclipse as ide, so it should be possible to write such a custom validator - any hints for a good starting point?
The validator should show a warning in eclipse if the parameter in the TableColumn(parameter) isn't final (should be a literal or constant). The validator should show an error in eclipse if the TableColumn is added to TableColumns and the corresponding Bean.getParameter() doesn't exist.
as we use SonarQube for quality checking, we could also implement a custom rule checking if the methods do exist - not completely sure if such a custom rule is possible (probably yes)
maybe other solutions that will give a fast feedback within eclipse that some tables won't render correctly after some getter methods were renamed
What I'm asking for:
what will be easier in this situation: writing a custom validator for eclipse or writing a custom rule for SonarQube?
hints where to start either approach
hints for other solultions
Thanks for your help.
Some alternatives:
You could migrate to more modern Java for this pattern, it is a prime candidate for method references. Then, your IDE of choice can automatically take care of the problem when you refactor/rename. This can be done bit-by-bit as the opportunity/necessity arises.
You could write your own custom annotations:
Which you can probably get SonarQube to scan for
Which could allow you to take advantage of javax.validation.* goodies, so your code may look/feel more like 'standard' Java EE code.
Annotations can be covered by a processor during the build step, various build tools have ways to hook this up -- and the processor can do more advanced/costly introspection so you can push the validation to compile-time as opposed to run-time.
I'm currently in the process of creating an extension for Liquibase to support Cassandra. It's working pretty well but I want to add some nice-to-have functionality.
When a changeset has a precondition, I want to throw something like a NotSuppportedException() or whatever. Problem is that currently, the underlying JDBC wrapper returns a closed ResultSet which results in an Exception being thrown upon access to said ResultSet.
For Statements, I implemented my own Generators. Is there a similar thing for preconditions? Or a way to override the existing ForeignKeyExistsPrecondition implementation? Extending from the class and overriding the check method doesn't work (even if placed in the package liquibase.precondition.ext).
Thanks!
The only way this seems to work (thanks to #dag) is using the exact same FQDN as the Precondition I want to override.
How can I retrieve the latest value from BehaviorSubject on RxAndroid?
Some background info: I'm using RxJava to implement MVVM pattern. My ViewModel encapsulates "bindable properties" that are BehaviorSubjects. I'm binding them to UI elements as observables, ensuring that the interface gets constantly updated (and thanks to using BehaviorSubject, it's going to happen even if the subscription takes place after setting the value).
I would still like to be able to access the latest (the actual) "raw" value of the property, for business logic.
How do I do that?
Surely BehaviorSubject caches it somehow, given that it republishes the latest value for whoever subscribes to it.
And yet BehaviorSubject.last() only returns an Observable<T>, and it doesn't seem to expose any methods of T return type.
I know I could cache it myself, but it feels redundant.
I guess I could also create a throw-away subscription in my getter, only to obtain the latest value with it and then return it to the calling code, but this seems clunky.
Is there anything neater on hand?
As it turns out, the reason behind it is that RxAndroid by default depends on RxJava 1.0.4, where Subjects didn't expose getValue nor hasValue yet.
Thanks to #akarnokd for helping me realize that.
As it turns out, all it takes to resolve the problem is to manually add a dependency on latest version of RxJava side-by-side with RxAndroid dependency in build.gradle. As of now that would be:
compile 'io.reactivex:rxandroid:0.24.0'
compile 'io.reactivex:rxjava:1.0.11'
See https://github.com/ReactiveX/RxAndroid/issues/171
It would be helpful if you use blockingGet()
subject.onNext(subject.blockingLast(null))
I was working on validation using annotation in Struts2 and i was quite surprised to see that the annotations does not have a LongRangeFieldValidator where as the validations done using xml does have a LongRangeFieldValidator
I tried different ways to get the LongRangeFieldValidor using annotations.
LongRangeFieldValidator. It showed an error because it doesn't actually exists and com.opensymphony.xwork2.validator.validators.LongRangeFieldValidator cannot be converted to an Annotation type. This was quite obvious so i switched to next.
I used IntRangeFieldValidator. I could quite use it because it was unable to do a typecasting. I thought this should have worked because docs says it is for numeric types.
DoubleRangeFieldValidator This one also validates (and it should) non-integer values so i had to drop this.
Finally I had to convert my long field to a String and had to use RegexFieldValidator.
My question is why there isn't a LongRangeFieldValidator in the package com.opensymphony.xwork2.validator.annotations and what are the best practices to obtain it?
It seems they forgot to add this annotation to the core package. Just a mistake may be or so, but there is the workaround. Use a custom validator annotation
#CustomValidator(type ="long", fieldName = "myField")
under registered validators you can find the name of the validator long.
IntelliJ currently provides code completion / checking for HQL queries that are used directly in creating queries.
Is there any way to enable this checking on Strings? The strings are then passed down to objects that create the query, so it would be beneficial if we could have them checked at compile time.
We found the answer - in Settings / Language Injections, you can add a new "Java Paramter" / "Hibernate QL" setting and specify the class that you wish to enable the content assist for.