[HSEARCH] Autodiscoverable field bridges next steps
by Emmanuel Bernard
There has been a lot of discussions on the PR. Let me try and sum up my next steps and bootstrap some discussions.
To comment on a specific subject, create a separate thread per subject or this thread will be come a huge radiated tree :)
## @IndexedEmbedded and null
Apparently both Sanne and I discovered a feature implemented a while ago :)
There are some questions around it so I opened a separate issue to deal with the question https://hibernate.atlassian.net/browse/HSEARCH-1578
## References to field bridges
Despite being on an internal class, some implementations (Infinispan remove query at least) uses direct references to FieldBridge.SOME_BRIDGE.
I’ll reinstate them so that Sanne could integrate continuously HSearch 5 with Infinispan. I would prefer to see them go esp when we have the free form entity support and the idea of field bridge composition done.
https://hibernate.atlassian.net/browse/HSEARCH-1579
BTW can I move these references? Or should they stay on BridgeFactory?
## Handling duplicates
I had in mind the following logic.
Prevent custom bridge providers to offer bridges in the same situation. That would be an error at start up time as the alternative of picking up one of them does not seem very attractive. Then built-in bridges would be taken into account. It means that a custom bridge would be able to override a built-in bridge.
Another alternative is to explicitly give ordering priorities to between providers. I’d rather not go that way if possible.
Sanne questioned the idea of built-in bridge and would rather have all bridges handled equally and not allow duplication.
It seems that the current set of bridges cannot support that approach. When I developed the code, I realised that there is an ordering to respect. If I put the TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest fails. I could not find why but it shows that we have some interdependencies at the moment.
## Splitting the BridgeProvider in two methods
A way make the inelegant code structure
FieldBridge bridge = provider.provide(…);
if ( bridge != null ) {
return bridge
}
Is to ask of the provider to answer two question:
- boolean canProvideBridgeFor(…)
- FieldBridge createFieldBridge(…)
The code would become
if ( provider.canProvideBridgeFor(…) ) {
return createFieldBridge(…)
}
I will experiment with it to see if it creates in practice too much duplication of code at the provider level. Another concern is that if the answer to can… and create… are inconsistent, we are in trouble.
## AnnotatedElement
Hardy does not like us being tied to the actual physical annotation objects. I tend to agree with him as we would need to fake it for free-form entities.
Since he worked on Jandex and the ORM side of parsing, he will work on a proposal that abstracts us away from AnnotatedElement.
The alternative is to pass the XLayer objects but not everyone is fine of that abstraction.
## BridgeProvider Context object
I’ll change the BridgeProvider to offer some kind of Context object instead of the list of parameters we have today. That will make it more future proof.
## Finish the BridgeProvider conversion
I’ll finish the conversion of the BridgeFactory to delegate as much code to BridgeProviders
## Implementation of the service loader based discovery
Hardy proposes to make each BridgeProvider a Service in the ServiceManager sense. The idea being that when we make a compatible ServiceManager OSGi wise, it will also make a compatible bridge provider discoverer.
It looks fine to me but as Hardy pointed out, we would need to make the ServiceManager accept several implementations per Service.
I’d like to separate the bridge auto-discoverability feature from that ServiceManager improvement to stay focused.
We can converge the service discovery as soon as the SM gains the right capability.
Emmanuel
10 years, 9 months
[HSEARCH] Question on TikaBridge
by Emmanuel Bernard
Hardy,
Today the actual bridge fails during set() if the object passed is not of a specified subset of types (Blob, etc).
This means the failure happens at the first indexing usage.
Is that ok / preferable if I do these type checking at the bridge creation time - in the BridgeProvider. The only thing I cannot handle here is if the user declares the return type as Object and the runtime type happens to be an acceptable type.
It seems like a small flexibility loss and we would gain clearer error messages: if something is annotated @TikaBridge and we don’t support the type we will fail fast.
Can i make that change?
10 years, 9 months
[OGM] OGM and Bean Validation
by Gunnar Morling
Hi,
Working on a demo for OGM, I tried to apply Bean Validation constraints to
my entities and have them automatically validated during the persistence
lifecycle.
This works as expected (which is very nice), the only thing which made me
wonder is that the resulting ConstraintViolationException is wrapped into a
RollbackException. Basically that's not surprising as we use TX demarcation
to control the flush cycle also if the store is actually non-transactional,
yet it may cause irritations and false expectations by users.
So I'm wondering whether we rather should raise a more generic
PersistenceException (or another specialized type which doesn't indicate a
rollback may happen) when using a non-transactional backend? What do you
think?
--Gunnar
10 years, 9 months
Another @Access quandry
by Steve Ebersole
>From the test
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
we have the following:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
The test asserts that this is a valid mapping. Granted that the spec is
very unclear here, so I might be missing something. The pertinent spec
section here states:
*<quote>When Access(PROPERTY) is applied to an entity class, mapped
superclass, or embeddableclass, mapping annotations may be placed on the
properties of that class, and the persistenceprovider runtime accesses
persistent state via the properties defined by that class. All proper-ties
that are not annotated with the Transient annotation are persistent.
WhenAccess(PROPERTY) is applied to such a class, it is possible to
selectively designate indi-vidual attributes within the class for instance
variable access. To specify a persistent instancevariable for access by the
persistence provider runtime, that instance variable must be desig-nated
Access(FIELD).</quote>*
I can see a few different ways to read that:
1) @Access can be placed on the attribute to define both where to look for
mapping annotations and the runtime access strategy for a given attribute.
Here, we'd do:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Id
@GeneratedValue
@Access(AccessType.FIELD)
private long id;
...
public long getId() {
return id;
}
...
}
2) @Access can be placed on the attribute to define the runtime access
strategy for a given attribute, but the class/hierarchy AccessType controls
where to look for mapping annotations. This would lead to:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Access(AccessType.FIELD)
private long id;
...
@Id
@GeneratedValue
public long getId() {
return id;
}
...
}
The test seems to illustrate that our legacy code made yet a 3rd reading of
this passage such that @Access is still considered a "mapping annotation"
even though that seems to directly contradict "To specify a persistent
instance
variable for access by the persistence provider runtime, that instance
variable must be desig-
nated Access(FIELD)."
Is there some other passage I am missing that bears on what to do here?
How do y'all feel about that passage and its implications on this test
mapping?
10 years, 9 months
Re: [hibernate-dev] [OGM] CI jobs hang (Gunnar Morling)
by Paolo Antinori
Hi Gunnar
I am working on related activities on a replica of ci.hibernate.org where I
am playing with Docker and trying to see how well it could fit the the
project build needs.
When running OGM build job on this replica server, I have noticed the same
problem.
I think that the problem is related to Axis plugin, like you were pointing
out.
I have also noticed this:
http://ci.hibernate.org/job/hibernate-ogm-master/106/consoleText
That is the link for the plain text version of the logs.
Not sure if the message you find there:
No such file: /var/lib/jenkins/jobs/hibernate-ogm-master/builds/2014-04-01_07-01-01/log
Is the blocking problem or just a side-effect of something else.
I hope to be able to show soon a Docker based approach to possibly bypass
totally this kind of problems.
paolo
On Tue, Apr 1, 2014 at 12:46 PM, <hibernate-dev-request(a)lists.jboss.org>wrote:
> Send hibernate-dev mailing list submissions to
> hibernate-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
> hibernate-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> hibernate-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
> Today's Topics:
>
> 1. [OGM] CI jobs hang (Gunnar Morling)
> 2. Re: Session and carrying 3rd party state (Gunnar Morling)
> 3. Re: Session and carrying 3rd party state (Gunnar Morling)
>
>
> ---------- Forwarded message ----------
> From: Gunnar Morling <gunnar(a)hibernate.org>
> To: "hibernate-dev(a)lists.jboss.org" <hibernate-dev(a)lists.jboss.org>
> Cc:
> Date: Tue, 1 Apr 2014 09:20:28 +0200
> Subject: [hibernate-dev] [OGM] CI jobs hang
> Hi,
>
> For some reason, the CI jobs for OGM can't be executed (all jobs, master,
> java8, PR seem affected) . They hang forever in an initial state, i.e.
> there is no console output and also the sub-jobs are not dispatched (these
> are matrix projects). Worse, they can't even be canceled (trying to do so
> has no effect), only a server restart helps.
>
> Have there been any recent changes to the job (or server) config which may
> cause this? I found https://issues.jenkins-ci.org/browse/JENKINS-9688which
> indicates, that the jobs may be waiting eternally for a resource which they
> can't acquire (I don't see any resources requested in the job config, but I
> vaguely remember something around JGroups channels).
>
> Does anyone know what's going on here?
>
> --Gunnar
>
>
>
10 years, 9 months
[OGM] Move container integration test to a separate default test cycle
by Emmanuel Bernard
This is a follow up on
https://github.com/hibernate/hibernate-ogm/pull/307#issuecomment-38453092
We keep piling up new backends, new containers to test and new rules
checked at build time. A consequence is that it is becoming less and
less pleasant to work on OGM.
You can see that n version of Naked+WF+EAP+... multiplied by m backends
simply will make this project horrendously slow to contribute to.
I imagine n = 3 or 4 and m = 10 in a medium term.
I see two options that would keep us around for a while:
1. Make the container integration tests only run with a specific option
activated on the CI.
2. Move the container integration tests outside in a different repo
altogether.
I do prefer 1.
Emmanuel
10 years, 9 months
