[hibernate-dev] [OGM] Hibernate OGM @ Devoxx

[Guillaume SCHEIBEL]

Hello,

After SoftShake (and few JUGs), I'm proud (and kind of exited) to announce
my Tool In Action titled "a hint of NoSQL into my Java EE" has been
approved.

See you there :)
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Fwd: Re: Required improvements for Infinispan's query engine

[Adrian Nistor]

forwarding this to the list too (hoping this time is not rejected by 
mail server)


 Original Message 
Subject:Re: [hibernate-dev] Required improvements for Infinispan's 
query engine
Date:   Mon, 09 Sep 2013 17:06:14 +0300
From:   Adrian Nistor 
To: Gunnar Morling 
CC: Hibernate Dev , Emmanuel Bernard 




Hi Gunnar,

I currently use a single generic indexed entity which represents the 
multitude of protobuf defined domain types. This approach is not 
necessarily ideal but was forced to adopt it because of the way hsearch 
currently works. Other projects do the same (ModeShape is one such example).

Having an SPI so I can provide my own field bridges seems like a good 
idea that would solve my current needs.

Thanks,
Adrian

On 09/08/2013 02:33 PM, Gunnar Morling wrote:
> Hi Adrian,
>
> We have been contemplating some ideas around your requirements. Are 
> you working with several "types" (as defined by ProtoBuf files) or 
> only one such type per one of your caches (and thus afaics SearchFactory)?
>
> In case of the latter, one idea would be that you always target your 
> generic entity type with your queries and we provide an SPI which 
> allows you to configure the field bridges to be applied for the 
> individual fields of a given entity (here always the generic entity 
> type), e.g.  FieldBridge getFieldBridge(Class type, String 
> fieldName). We could then query this SPI from within the HSEARCH-based 
> parser backend to apply the right field bridges for a given query. You 
> would create any FieldBridge instances yourself and thus could inject 
> whatever data you need into them.
>
> Would this address the needs of Infinispan?
>
> If you need to work with several ProtoBuf types per SearchFactory, 
> we'd have to do some more changes within HSEARCH, as the metadata 
> essentially is keyed by class type atm. and we'd have to change that 
> to key by a more type representation.
>
> Thanks,
>
> --Gunnar
>
>
> 2013/8/31 Emmanuel Bernard  >
>
> Adrian found a few problematic limitations in Hibernate Search during
> its integration of the HQL query parser and the Hibernate Search back
> end.
>
> Composite bridge::
> https://hibernate.atlassian.net/browse/HSEARCH-1397
>
> Injection of services into a FieldBridge::
> https://hibernate.atlassian.net/browse/HSEARCH-1396
>
> These two are important for Infinispan 6 and should be give priority.
> I think they can be added in 4.4 without too much effort.
>
> Thoughts?
>
> Otherwise, support for mapping non Java object structures is something
> we should do in Hibernate Search. For 5?
> Is there a JIRA for it?
>
> Emmanuel
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>



___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Native-SQL queries and flushing

[Steve Ebersole]

We will need to make a slight change to execution of native SQL queries 
in order to pass the JPA 2.1 TCK.  The new TCK tests that execution of a 
native SQL query does an "auto flush".

The problem with this is that, unlike with HQL/JPQL, we do not know the 
tables affected by a native SQL query (and doing so would be extremely 
difficult and not worth the effort).  Historically, Hibernate users 
would have relied on the 
addSynchronizedQuerySpace/addSynchronizedEntityName methods of 
org.hibernate.SQLQuery to indicate the tables needing flushed.  JPA 
however has no such notion.

As I see it, I think the change here needs to be to implicitly perform a 
*full flush* when a JPA native SQL query is executed where the 
wrapped/underlying org.hibernate.SQLQuery does not define any "query 
spaces"; a partial flush just is not possible in that case. That allows 
us to pass the TCK, but still allows users to set "query spaces" if they 
wish to do the more efficient partial auto-flush.

Any alternate suggestions?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev