ORM 4.3 Beta4 release delayed
by Steve Ebersole
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.
10 years, 7 months
Native-SQL queries and flushing
by 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?
10 years, 7 months
Re: [hibernate-dev] Required improvements for Infinispan's query engine
by Gunnar Morling
2013/9/9 Adrian Nistor <anistor(a)redhat.com>
> 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).
>
Do you have a pointer for me where I can find your code integrating with
the parser? What I'm trying to find out is whether your GenericEntity is
used to map several of your ProtoBuf domain types in the context of one
SearchFactory instance or not.
If this the case, the SPI would need to work with a more abstract
representation of types than class objects, e.g.
getFieldBridge("com.example.MyDomainEntity", "myProperty") and also the
changes within HSEARCH will be a bit larger. If GenericEntity represented
always exactly one domain type in the context of one SearchFactory
instance, we could have the SPI look like
getFieldBridge(GenericEntity.class, "myProperty"), and hooking things into
HSEARCH would become a bit simpler.
> 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 <emmanuel(a)hibernate.org>
>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>
10 years, 7 months
Fwd: Re: Required improvements for Infinispan's query engine
by 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 <anistor(a)redhat.com>
To: Gunnar Morling <gunnar(a)hibernate.org>
CC: Hibernate Dev <hibernate-dev(a)lists.jboss.org>, Emmanuel Bernard
<emmanuel(a)hibernate.org>
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 <emmanuel(a)hibernate.org
> <mailto:emmanuel@hibernate.org>>
>
> 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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
10 years, 7 months
Re: [hibernate-dev] hiberate-commons-annotations and locating annotations
by Steve Ebersole
After looking through this some more, I think what you say could almost
work. But:
1) Still need a way to determine the declarer of a property rather than
just blindly accepting XProperty.getAnnotation(Convert.class). This is
needed for the Super/Sub MappedSuperclass/Entity case in my initial
email to properly interpret Convert precedence. Is the best option
here a change to hibernate-commons-annotations, and if so what change
specifically? Adding `XClass XProperty#getDeclarer()`?
2) As you say, AbstractPropertyHolder does account for
subclass/superclass precedence during its init. But I am not sure how
to hook in normalized path-based handling here.
2.a) It seems like there are times when
org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for
what I need to do. But there appears to be times when this is null.
For entity mappings (ClassPropertyHolder) thats fine. But for the
others, that would be problematic. Going back to the
Person#homeAddress example, I'd really need the ComponentPropertyHolder
for Person#homeAddress to register the converts with
ClassPropertyHolder<Person> under the "homeAddress" base key
("homeAddress.city" for example). Is there a time here where
AbstractPropertyHolder#parent would be null for
ComponentPropertyHolder/CollectionPropertyHolder?
2.b) Is this AbstractPropertyHolder#parent the best way you see to
handle path-based converts? Or do you see a better option?
On Fri 30 Aug 2013 10:52:40 AM CDT, Emmanuel Bernard wrote:
> On Fri 2013-08-30 10:13, Steve Ebersole wrote:
>> Hit send too early...
>>
>>
>> On 08/30/2013 09:55 AM, Steve Ebersole wrote:
>>> Also, unless we have some normalization rules, my point was that
>>> we literally cannot do this today in annotations.
>>>
>>> Essentially the bug-a-boo is composites (and maybe collections as
>>> composite via allowance of "map.", etc). We'd essentially have to
>>> normalize all paths for converters to be the composite form
>>> relative to the "root" composite parent. In other words, given
>>> the "Person.homeAddress.country" example (home address being
>>> embedded of type Address), we'd have to normalize all path
>>> references for converters to be "homeAddress.country" and
>>> kept/managed on Person. The trouble is that this makes the order
>>> in which we process these levels very important, and I am just not
>>> sure I trust binders as they are to enforce that ordering.
>>
>> This ^^ is difficult to achieve in the "annotation reader".
>
> That's what is done for Attribute Override in AbstractPropertyHolder.
> You can control the order in which sub/spuer class a processed it and
> control how composition from a property holder to its parent is done.
10 years, 7 months
Feature for handling getNextValue work in same transaction.
by Jeremy Whiting
Hi,
I am looking for feedback on changes to provide the ability for work
to be completed in a currently running transaction. For example when a
TableGenerator or SequenceGenerator is being used for generating unique
ids. The statements that select then update the db are executed in a
separate transaction.
There is a jira for this feature.
https://hibernate.atlassian.net/browse/HHH-8429
Attached to the jira is a diagram. See this link
https://hibernate.atlassian.net/secure/attachment/19534/hibernate-class-s...
This diagram shows what I currently have implemented. It shows the
existing classes and the new classes shaded in light blue. The methods
on a new class IsolationAware show how I've re-jigged most the
implementation from JtaTransaction to it's new ancestor IsolationAware.
A new concrete implementation of IsolationDelegate will negotiate the
work to be executed in the same running transaction.
The structure splits up the factory/transaction/delegate classes into
two groups. "same transaction" and "separate transaction". This has only
been done for JtaTransaction and the same will probably be necessary for
CMTTransaction as it also uses a separate transaction to complete work.
That has been left out to keep the diagram simple.
The option of using aggregation at the point where implementers of
TransactionImplementor are instantiated has been considered. Before too
much effort is expended coding I wondered what others thought is the
preferred way to implement this feature.
Jeremy
10 years, 7 months
