Re: [hibernate-dev] Native-SQL queries and flushing
I never heard alternatives, so this is now implemented as described below. https://hibernate.atlassian.net/browse/HHH-8487 On Tue 10 Sep 2013 12:05:35 AM CDT, Steve Ebersole wrote: > 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
[hibernate-dev] ORM 4.3 Beta4 release delayed
I had planned on releasing 4.3 Beta4 today, but JBoss's Nexus repo is under the weather. Let's assume it will be fixed by tomorrow and plan on the release then. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Decoupling indexed types from their class definitions
Some other projects use Hibernate Search - specifically the engine module - to bridge their domain model to a Lucene index and take advantage of its high performance low-level integration with Lucene. This is generally achieved by indexing a "valueholder" object which has most logic to create a custom o.a.l.Document in a top level @ClassBridge, or by using some custom FieldBridges, but has some strong limitations and feels more like a hack. In Hibernate Search 5.0 we will make this more flexible, so to move away from an annotated-entities index engine only to make it easier to index objects whose "schema" is more flexible than the contraints imposed by the staticness of a compiled Java class. We've discussed however to introduce some of these features right now (in version 4.4), so that we can start exploring the direction gradually and get some early feedback. In particular what seems to be troublesome is to implement multiple "user types" using the same type (java type) as valueholders: the trouble is to filter on the correct user type where the Hibernate Search APIs expect - as basic filtering strategy - a java Class instance, or simply to have the flexibility to configure separate backends for each user type. So this first refactoring [HSEARCH-1402] will be about moving the *internal* contract - without changing public APIs - to use a different identification than the current Class when we lookup for indexing information for a specific indexed type. Comments very welcome. Sanne - https://hibernate.atlassian.net/browse/HSEARCH-1379 Explicit support for indexing free-form (dynamic) entities - https://hibernate.atlassian.net/browse/HSEARCH-1402 Allow explicit user control of ProjectionConstants.OBJECT_CLASS value during indexing - https://hibernate.atlassian.net/browse/HSEARCH-1404 More flexibility than just Class to identify indexing metadata ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
