>>> Is that ok / preferable if I do these type checking at the bridge creation
>>> time - in the BridgeProvider.
>>
>> Not sure. AS you say, the problem is if you define the type as Object.
>> Probably quite uncommon.
>
> I'd enforce it. If a getter guarantees to provide a refined type, it
> c
On 2 April 2014 19:42, Hardy Ferentschik wrote:
>
> On 2 Jan 2014, at 18:30, Emmanuel Bernard wrote:
>
>> Hardy,
>>
>> Today the actual bridge fails during set() if the object passed is not of a
>> specified subset of types (Blob, etc).
>
> Right, that happens in TikaBridge#getInputStreamForData
On 2 April 2014 22:20, Emmanuel Bernard wrote:
> Please everyone and especially Sanne, read this branch of the exchange Hardy
> and I have. We need another pair of eyes to make sure we don’t mess things up
> as it is an important departure compared to how things are done today (and in
> my prot
It’s actually a PITA even in JPA. I wish ConstraintViolationExceptions were not
wrapped at all.
On 03 Apr 2014, at 00:00, Gunnar Morling wrote:
> Hum, I guess it's one of the cases then where JPA doesn't 100% match for the
> purposes of talking to NoSQL.
>
>
> 2014-04-02 17:40 GMT+02:00 Emma
Hum, I guess it's one of the cases then where JPA doesn't 100% match for
the purposes of talking to NoSQL.
2014-04-02 17:40 GMT+02:00 Emmanuel Bernard :
> This would go against the JPA spec unfortunately.
>
> On 02 Apr 2014, at 16:25, Gunnar Morling wrote:
>
> > Hi,
> >
> > Working on a demo fo
Please everyone and especially Sanne, read this branch of the exchange Hardy
and I have. We need another pair of eyes to make sure we don’t mess things up
as it is an important departure compared to how things are done today (and in
my prototype).
Hardy, I am starting to come along your side on
On 2 Jan 2014, at 14:30, Emmanuel Bernard wrote:
>>> 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 realise
On 2 Jan 2014, at 17:37, Emmanuel Bernard wrote:
> Yes your analysis is correct.
Cool, so we seem to be on the same page then.
> I do think 3 is the most valuable but that 2c is a relatively close second.
+1 for case #3 being the most important one. I would even go so far to say that
this is
On 2 Jan 2014, at 18:30, Emmanuel Bernard wrote:
> Hardy,
>
> Today the actual bridge fails during set() if the object passed is not of a
> specified subset of types (Blob, etc).
Right, that happens in TikaBridge#getInputStreamForData
> This means the failure happens at the first indexing us
To wrap up for now... I went ahead an implemented the strategies we
discussed here. They are represented as:
1) org.hibernate.metamodel.spi.StandardPersistentAttributeMemberResolver
2) org.hibernate.metamodel.spi.LenientPersistentAttributeMemberResolver
StandardPersistentAttributeMemberResolver i
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
Hi Gunnar,
here a small preview of what I am working with at the moment.
Everything is still in beta so technically everything can change in future.
I am working mainly on 2 fronts:
1) allow in-container compilation.
This should help to isolate concurrent build from the network point of
view(no
This would go against the JPA spec unfortunately.
On 02 Apr 2014, at 16:25, Gunnar Morling wrote:
> 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 expec
Yes your analysis is correct.
I would clarify that 3 or 2c don’t have to apply on already supported return
types, it is more likely custom types like JodaTime types.
I do think 3 is the most valuable but that 2c is a relatively close second.
Now the @Spatial and @TikaBridge annotations do have a
http://in.relation.to/Bloggers/HibernateORM435FinalReleased
Brett Meyer
Red Hat, Hibernate ORM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On 01 Apr 2014, at 22:07, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Handling duplicates
>>
>> I had in mind the following logic.
>>
>> Prevent custom bridge providers to offer bridges in the same situation.
>
> What do you mean with "in the same
On 01 Apr 2014, at 22:20, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## 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.
https://hibernate.atlassian.net/browse/HSEARCH-1581
On 01 Apr 2014, at 22:24, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Implementation of the service loader based discovery
>>
>> Hardy proposes to make each BridgeProvider a Service in the ServiceMa
On 02 Apr 2014, at 03:04, Sanne Grinovero wrote:
>>> Another concern is that if the answer to can… and create… are inconsistent,
>>> we are in trouble.
>>
>> Well, if canProvideBridgeFor returns true it should create the bridge when
>> provide is called. Unless there is of course an (runtime)
On 01 Apr 2014, at 22:19, Hardy Ferentschik wrote:
> Also in the real world, you would first ask me whether I can make you
> something, before telling me to do so, right?
Well in real life I guess you get all kinds of design.
- directly tell someone to do it and complain if that’s not done
-
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
On 2 Jan 2014, at 04:20, Steve Ebersole wrote:
> I have heard no more comments, so I will move forward with this as stated
> earlier.
Sorry for the late reply. I had a read through and what you describe is what I
would expect (in fact I hope
I basically implemented it this way on the metamode
On 1 Jan 2014, at 22:07, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Handling duplicates
>>
>> I had in mind the following logic.
>>
>> Prevent custom bridge providers to offer bridges in the same situation.
I am still trying to wrap my head around
On 2 Jan 2014, at 12:10, Emmanuel Bernard wrote:
> I don’t think copying these 15 or 30 field bridges implementations is really
> a good thing. In the end, we will have to support them anyways in JDG if the
> problem is not solved at the root instead of shifted to the next lib.
My understandi
On 2 Jan 2014, at 03:04, Sanne Grinovero wrote:
> On 1 April 2014 21:19, Hardy Ferentschik wrote:
>>
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>>
>>> ## Splitting the BridgeProvider in two methods
>>>
>>> A way make the inelegant code structure
>>>
>>> FieldBridge bridge = prov
On 1 Jan 2014, at 22:55, Gunnar Morling wrote:
> 2014-04-01 22:19 GMT+02:00 Hardy Ferentschik :
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
> > ## Splitting the BridgeProvider in two methods
>
>
> FWIW, I side with those preferring a single method and doing a null check.
>
> It'
https://hibernate.atlassian.net/browse/HSEARCH-1581
On 01 Apr 2014, at 22:24, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Implementation of the service loader based discovery
>>
>> Hardy proposes to make each BridgeProvider a Service in the ServiceMa
I don’t think copying these 15 or 30 field bridges implementations is really a
good thing. In the end, we will have to support them anyways in JDG if the
problem is not solved at the root instead of shifted to the next lib.
On 01 Apr 2014, at 22:02, Hardy Ferentschik wrote:
>
> On 1 Jan 2014,
I going to update Jenkins and the plugins to see if it solves this issue.
Are there any reasons I shouldn't do this?
On Tue, Apr 1, 2014 at 2:11 PM, Gunnar Morling wrote:
> Hi Paolo,
>
> Thanks for your reply. The thing is that these jobs used to work until
> recently, so I'm wondering which c
+1 for option #1. Note that you already today can skip all integration
tests by adding -DskipITs to your Maven command.
I think it'd make sense have a single module which houses all the
integration tests which can then be executed against all possible
container/datastore combinations. By default w
We discussed various things
* Neo4J backend + query implementation
* bridge autodiscovery
* CI OGM instability
* Hibernate Search roadmap
* pros and cons of 2 weeks release cycles
* plans for an OGM roadmap with dates right after summit
Meeting ended Tue Apr 1 14:50:48 2014 UTC. Information ab
31 matches
Mail list logo
