GitHub Split View
by Hardy Ferentschik
Hi,
Not sure for how long it is there already, but GitHub has now
a side by side diff view for pull request changes (on the Files
changed tab look for the unified vs split buttons).
This discovery made my day, so I thought its worth sharing ;-)
--Hardy
10 years, 2 months
Possible bug in hibernate-validator ValidatorImpl
by Itai Frenkel
Hello,
TL;DR: Need an opinion if to open a JIRA (since reproduction is very tricky)
I am using the @UnwrapValidatedValue with a custom Guava OptionalUnwrapper and sometimes OptionalUnwrapper#getValidatedValueType() is called also for non-Optional<> fields.
The bug reproduction is sporadic and tricky. I managed to pinpoint it to ValidatorImpl#setValidatedValueHandlerToValueContextIfPresent() that does not perform valueContext.setValidatedValueHandler( null ) when there is no need for an unwrapper. Since valueContext is re-used between fields, it is possible for the OptionalUnwrapper to be first called for Optional fields and then re-used for non-Optional fields with the same validatedValueHandler of the Optional field.
If the code owner could quickly comment on this, it would be great.
below are some code snippets I used.
public class SomePOJO {
@DecimalMin(value="0", inclusive=true)
public Integer x = -1;
@UnwrapValidatedValue
@DecimalMin(value="1", inclusive=true)
public Optional<Integer> y = Optional.of(-1);
@DecimalMin(value="0", inclusive=true)
public Integer z = -1;
}
public class OptionalUnwrapper extends ValidatedValueUnwrapper<Optional<?>> {
private final TypeResolver typeResolver;
public OptionalUnwrapper() {
typeResolver = new TypeResolver();
}
@Override
public Object handleValidatedValue(Optional<?> optional) {
return optional == null? null : optional.orNull();
}
@Override
public Type getValidatedValueType(Type valueType) {
final TypeToken<?> typeToken = TypeToken.of(valueType);
if (typeToken.getRawType().isAssignableFrom(Optional.class)) {
Type rawType = typeToken.resolveType(Optional.class.getTypeParameters()[0]).getType();
return rawType;
}
else {
Type rawType = typeToken.getType();
Preconditions.checkArgument(false, "type " + rawType + " is not supported by " + this.getClass() );
return null;
}
}
}
10 years, 2 months
Advice - cyclic event handling
by Steve Ebersole
As part of the metamodel work, one of things I am working on is redesigning
the old notion of a "second pass" to be more efficient. For those not
familiar, this represents a piece of processing that needs to be delayed
until after another piece of processing is done. For example, processing a
composite identifier metadata for an entity might depend on the identifier
metadata for another entity being processed first.
"second pass" was essentially one big bucket. In the new design I am
trying to categorize or segment these things better, so we have different
buckets (one for identifier metadata completion, one for attribute Type
metadata completion, etc).
Not to get too involved, but essentially a bucket is a List of "watchers"
for specific "happenings" (I think of them as events, but am trying to
avoid that terminology for now). E.g., take the "identifier metadata
completion" bucket. As we complete the binding of the identifier metadata
for an entity, we fire off a notification of that happening. The watchers
can then react to that notification.
The implementation of this is a List of watchers, as I said, which is
iterated over for each notification. So here comes the trickiness. As
each watcher is finished it needs to be removed from the list of watchers.
And a watcher could in turn kick off a new notification (for it completing
whatever it represents). So in the initial impl I ran into
ConcurrentModificationException problems.
I went ahead and made it work just to move forward. But I wanted to circle
back and design this "right"; so I wanted to get others involved to see if
anyone had thoughts or better ideas.
Here is a simple example to use as a basis for discussion: consider the
entity Customer and Order. Customer has a simple identifier, whereas Order
has a composite identifier made up of (1) FK to Customer and (2) a order
number. We need the identifier metadata for Customer to be completely
bound before we can process the identifier metadata for Order. That is the
crux of the problem to be solved. Its an ordering concern. If the
metadata for the Customer entity is processed first, no big deal. But of
course we can't really control that (putting the onus back on the user here
is fugly). So we need to account for the case where metadata for the Order
entity is processed first. This kind of timing thing is the reason for
second passes and these new notifications. The idea in the new design is
that we would register a watcher for Order which waits for the notification
that Customer identifier metadata has been finished. As the identifier for
each entity is completed, that process fires off a notification of that
fact. So as the identifier metadata for Customer is finished, the process
fires off a notification which makes its way back to the watcher for Order.
Processing can now bind the identifier metadata for Order, and in turn
fire off its notification.
The trouble here, in the iteration impl, is that we are still iterating
over the "identifier metadata completion" notification, so there is an
active iterator over the list. When performing the Order-watcher
processing, since it no longer needs to watch, we would ideally remove it.
Initially I had simply exposed a deregistration method that removed the
watcher from the list, but that ran into the problems with CME. What I do
currently instead is to expose a method on the watcher contract for the
watcher to say whether its work is done, and if so use the Iterator to
remove it. That works, just not sure its the best option.
Another consideration is the iteration over non-interested watchers. This
may be a non-issue, not sure yet. Currently watchers simply register as
being interested in identifier metadata completion notifications, not
notifications for completion of identifier metadata for specific entity(s).
So on the con side, the List would become a Map and we'd need a key
object. On the plus side we'd avoid the iteration and CME problems
altogether.
10 years, 2 months
Projecting an index
by Marc Schipperheyn
I'm wondering if would be conceivable to project a custom index based on
the programmatic API when you are also using Annotations?
Our use case is basically that we have a social "wall" where we retrieve
"posts" which can reference related objects: other posts, user info,
classifieds, events, groups, etc.
In most cases, we'll reference these with a title, url, description and
photo. Additionally, each object can have a specific property, such as an
event having a startDate and an RSVP.
We don't store this information directly in the post index because changes
in them could affect a large number of posts and have undesired
performance impacts
We are avoiding to load stuff from the database because of the load each
retrieval could generate and are basically loading as much as possible from
the index. One alternative approach would be to use the index to load post
ids and then load the posts as is from the database = large number of
queries through lazy initialization. We went the pure index way.
In order to load all this information each load of a list of posts requires
some preloading and some iterations to first load the posts and then load
related objects from their own indices. This kind of staggered approach
offers some nice caching opportunities.
But ideally, I would like to have a limited flattened index that contains
all the related data for a post, but that does allow me to automatically
update data in it if the underlying object changes.
ideally, I would like to store in that index something like this
object class
id
title
url
description
photo
[custom fields]
I'm curious if something like this would be achievable with HSearch?
10 years, 2 months
WildFly, JtaPlatform and Hibernate OGM
by Gunnar Morling
Hi,
Running an OGM integration test on WildFly, I noticed that we work with
JBossStandAloneJtaPlatform. Shouldn't it rather be
JBossAppServerJtaPlatform in this case so we make use of the transaction
manager from the container?
So I thought it might help to add jipijapa-hibernate4-3.jar to the OGM
module, as it provides HibernatePersistenceProviderAdaptor which in turn
sets the JBossAppServerJtaPlatform. This works indeed, but unfortunately
HibernatePersistenceProviderAdaptor always bootstraps Hibernate ORM by
calling ORM's EMF builder.
What'd be the right way to solve this problem? Have a specific JipiJapa
adaptor for OGM? Or could the existing one for ORM 4.3 actually be used if
it invoked the configured PersistenceProvider (HibernateOgmPersistence in
our case) rather than directly delegating to ORM's Bootstrap class?
Thanks,
--Gunnar
10 years, 2 months
