Search: renaming whole package (!)
by Sanne Grinovero
One of the last pending tasks for the Elasticsearch work is to
mass-rename all packages from
org.hibernate.search.backend.elasticsearch.*
to
org.hibernate.search.elasticsearch.*
It's trivial to do, but before proceeding I'd like to make sure that
all your important work was merged. All ready to proceed with this?
I plan to do it tomorrow at noon. If someone could merge the smaller
pending PRs in the meantime that would be nice.
Thanks,
Sanne
8 years
Storing SQL keywords in lowercase
by Vlad Mihalcea
Hi,
I tested and want to integrate this PR:
https://github.com/hibernate/hibernate-orm/pull/1011
However, there is this change in the Dialect class that seems reasonable,
but wanted to confirm that it will no break anything:
protected void registerKeyword(String word) {
// When tokens are checked for keywords, they are always compared to
the lower-case version of the token.
// Ex: INTEGER is always compared as integer. This can lead to
incorrect behaviour when registering custom keywords
// that are then used in formulas, as it is not made apparent that
formula query generation always looks at
// the lower-case token.
sqlKeywords.add(word.toLowerCase(Locale.ROOT));
}
For SQL functions, we do something similar:
protected void registerFunction(String name, SQLFunction function) {
// HHH-7721: SQLFunctionRegistry expects all lowercase. Enforce,
// just in case a user's customer dialect uses mixed cases.
sqlFunctions.put( name.toLowerCase( Locale.ROOT ), function );
}
This should be the right thing to do considering that
org.hibernate.sql.Template uses a lower case token as well:
String lcToken = token.toLowerCase(Locale.ROOT);
I see that only CUBRID and Derby Dialects register UPPERCASE keywords, so
I'm going to test it on Derby to see how it works.
Does anyone think that this change is going to break something in other
some other part which I might not be aware of?
Vlad
8 years
Hibernate OGM 5 released
by Davide D'Alto
Hibernate OGM 5.0.0.Final is out!
Compared to the 4.2.Final, this release is aligned with Hibernate ORM
5 and Hibernate Search 5, so you can easily use it with WildFly 10.
It supports Infinispan 8 and comes with a new back-end for Redis in
tech preview.
We improved the MongoDB CLI query syntax and we upgraded the MongoDB
Driver to version 3.
You can find more details about these new features and more on the
blog: http://in.relation.to/2016/05/17/hibernate-ogm-5-is-out
Thanks,
Davide
8 years
Possible regression on master
by Vlad Mihalcea
Hi,
While fixing tests for Oracle after rebasing my branch, I realized that the
org.hibernate.test.optlock.OptimisticLockTest > testOptimisticLockAllDelete
fails on Oracle10gDialect, while running just fine on H2.
When reaching the following branching logic in AbstractEntityPersister:
if ( useBatch ) {
session.getJdbcCoordinator().getBatch( deleteBatchKey ).addToBatch();
}
else {
check(
session.getJdbcCoordinator().getResultSetReturn().executeUpdate( delete ),
id,
j,
expectation,
delete
);
}
If using H2, we go to the useBatch branch, while for Oracle dialects that
are less than 12c (hibernate.jdbc.batch_versioned_data is set to false,
therefore JDBC batching is disabled) it goes on the second branch logic.
This way, for H2, a StaleStateException is thrown and the flush operation
flow is disrupted.
For Oracle, the check method call will throw a StaleObjectStateException
instead:
catch (StaleStateException e) {
if ( !isNullableTable( tableNumber ) ) {
if ( getFactory().getStatistics().isStatisticsEnabled() ) {
getFactory().getStatisticsImplementor()
.optimisticFailure( getEntityName() );
}
throw new StaleObjectStateException( getEntityName(), id );
}
return false;
}
Now, there is a difference between how the ExceptionConverterImpl handles
StaleStateException and StaleObjectStateException because for the latter,
it tries to fetch the entity in question:
final Object entity = sharedSessionContract.load( sose.getEntityName(),
identifier );
Because there is no proxy loaded in the current Session, the
DefaultLoadEntityListener will execute the createProxyIfNecessary method,
and because the entity was deleted, it will return null:
EntityEntry entry = persistenceContext.getEntry( existing );
Status status = entry.getStatus();
if ( status == Status.DELETED || status == Status.GONE ) {
return null;
}
However, getReference() throws an exception when there is no object being
found:
getFactory().getEntityNotFoundDelegate().handleEntityNotFound(
entityPersister.getEntityName(),
id
);
So instead of a StaleObjectStateException, we get
an ObjectNotFoundException.
One quick fix is to just catch that ObjectNotFoundException:
Object entity;
try {
entity = sharedSessionContract.load( sose.getEntityName(), identifier );
} catch(ObjectNotFoundException e) {
entity = null;
}
if ( entity instanceof Serializable ) {
//avoid some user errors regarding boundary crossing
pe = new OptimisticLockException( e.getMessage(), e, entity );
}
else {
pe = new OptimisticLockException( e.getMessage(), e );
}
Or maybe there is some other fix that you might think of.
Vlad
8 years
Returned mail: Data format error
by Post Office
�C���iH�8�����_���p�H�}����-�8��e*�P��Hm�D����J����A�e�
������T�W:Br�r�/�ZV��3��y���N(c��I�
'&���z�z������u�P,�2oq��oQ`�>2hu��B�U�:F���$���Ie�1�����Xp�a��K�S���$4�j�:C���kg��{�/���1������BL�����v��6�����m��#�����\%r�,��O)mZ�b
�f}�����<�:U�r�����H���j|��s�|�VF��������
g?�:wB�0�ZR������m���}O
�J�
X��lP�������y�!�9�
���m����TE���e$J�6�jl��K�]/)��
�l�qI�t�����4p�<��U?�oQlAZ�Go��b���W6��3���Z�D�!U��d9�������hGH`0���nO/E
G".<�u�X�e�<G�l#z*u������a85����M���e������^o�7�)2��`X#�LN���m-Z��^�����2��p"e�|-u3x�:�H1����/SF�sD�i��1"(��`{�����:��A�����E�{'�E���J��ji�6�!�#|�`v����fr
F
��p/�>
������
���~��8��K
(d��\{�o�p�!������%�G��[p��&�����]��{wq�sHkvs�[c8S(?�������V��6[����;�.�-�h[��
cN��
�vn$�����V�l���Y��u�3:rb/V�~���S�>����
UHh|]����Q����c���������o����2F,Gl��0j���5b����m�M_�R\"S��B���o���j�1���\��\���72\R
��cO^O������W���Y�(Jd�L%B�`�}n����4qK��eX�MJ���
8 years
Configuring lazy groups via XML
by Gunnar Morling
Hi,
As per an answer of Vlad in the forum [1], the lazy fetch groups new in ORM
5.1 are only supported via annotations.
Is that a temporary solution and XML support for lazy groups is planned
eventually (if not in HBM but then via some means of extension point in
orm.xml)?
In other words, is our strategy to keep annotations and XML (again, be it
HBM or through extensions in orm.xml) equally powerful? Or are we indeed
considering annotations as the "preferred way" and add new functionality
only there?
Personally I'd hope for the former, as there are use cases for both and it
should be left to users which one to take.
Taking a step back, it's not specifically XML I'm attached to, but *some
means* of external configuration of mappings as opposed to internal
configuration via annotations on the model itself. In the No-ORM projects
we provide APIs which allow to apply the same configuration as via
annotations for that purpose. Maybe that'd be a good thing for ORM, too?
Thanks,
--Gunnar
[1] https://forum.hibernate.org/viewtopic.php?f=1&t=1043183
8 years
