Re: [hibernate-dev] deprecate positional parameters?
https://hibernate.onjira.com/browse/HHH-7023
On Fri 03 Feb 2012 02:28:41 PM CST, Gail Badner wrote:
> +1 for me as well.
>
> - Original Message -
>> From: "Hardy Ferentschik"
>> To: "Hibernate"
>> Sent: Friday, February 3, 2012 7:44:48 AM
>> Subject: Re: [hibernate-dev] deprecate positional parameters?
>>
>> +1 for deprecating the HQL style positional parameters in this case.
>>
>> On Feb 3, 2012, at 4:31 PM, Steve Ebersole wrote:
>>
>>> The "force" is really 2 fold.
>>> First, yes there is problems when the resulting SQL query needs to
>>> be re-ordered for various reasons. The positional parameters
>>> sometimes end up in different orders from what they started. I
>>> *think* all those issues have been resolved now. The problem was
>>> that the code originally just assumed the position in the HQL and
>>> the position in the SQL would be the same in terms of order. IIRC
>>> I had to (1) separate the notions of positional parameter order
>>> and the positions they ended up in the SQL and then (2) add
>>> tracking between the 2 notions. So extra overhead there.
>>>
>>> Also, its confusing imo with the JPA notion of positional
>>> parameters. If the query uses jpa-style positional parameters,
>>> they have to be treated as named parameters in terms of binding to
>>> the org.hibernate.Query API. Our impl of javax.persistence.Query
>>> hides that complexity. But there is a mismatch between how those
>>> parameters are handled in the two APIs. Just so we are all clear
>>> on what this means...
>>>
>>> // HQL positional parameters:
>>> Query q = session.createQuery( "from Cat c where c.name = ?" )
>>>.setParameter( 1, "Tabitha" )
>>>...
>>>
>>> // JPQL style:
>>> Query q = em.createQuery( "from Cat c where c.name = ?1" )
>>>.setParameter( 1, "Tabitha" )
>>>...
>>>
>>> JPQL style, from Hibernate API:
>>> Query q = em.createQuery( "from Cat c where c.name = ?1" )
>>>.setParameter( "1", "Tabitha" )
>>>...
>>>
>>>
>>> On Fri 03 Feb 2012 07:18:49 AM CST, Hardy Ferentschik wrote:
And just use named parameters?
query.setString("name", "Fritz");
I don't think have a strong opinion on that. I am fine w/
deprecating it.
What is the driving force behind? I recall that there were some
Jira issues which
had some issues with positional parameters. Are they related?
--Hardy
On Feb 3, 2012, at 1:47 PM, Steve Ebersole wrote:
> What do y'all think about deprecating positional parameters in
> HQL? I
> am talking about the HQL-specific notion here, not the JPA notion
> of a
> positional parameter which we obviously have to continue to
> support.
>
> HQL positional params are in the form:
> from Cat c where c.name = ?
>
> w/ setParameter(1, "steve")
>
> --
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> --
>>> st...@hibernate.org
>>> http://hibernate.org
>>
>>
>> ___
>> 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
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Released: Hibernate Search 4.1.0.Beta1
Hello all, Hibernate Search 4.1.0.Beta1 is available! As usual, more details are at http://in.relation.to/Bloggers/HibernateSearch410Beta1ImproveInfinispanQueryMapping Regards, -- Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] More Git fun
Another thing we don't want to see is merges of pull requests pushed to the upstream repo. Our process is to rebase those changes in to keep the commit history linear. If you are not familiar with this process ask on irc. One place this comes up is using the "Merge Pull Request" button on the pull requests in the GitHub UI. Please refrain from using this. Again, ask on irc if you are not comfortable with that process. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Using Hibernate 3.6.x with Infinispan 5.1.1 as a second level cache and alternatives...
Hi, I have heard from some AS7 users over the past few months that are interested in using Hibernate 3.6.x with Infinispan 5.1.x as the second level cache. Galder already mentioned that Hibernate 3.6.x is targeted at Infinispan 4.x, so I understand part. My question and reason for this email, is to see if there is any interest in working with others that are experimenting with using Infinispan 5.1.x with Hibernate 3.6.x. As an alternative, would these users experience less friction, if they packaged Infinispan 4.x directly with their application (adding configuration/initialization code as needed). Scott ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
Feedback is welcome on a proposed change for HHH-7018
https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55a7d9c90b7126c5a5ae2
When we serialize the EntityManagerFactory in 4.0.0, there can be
nonserializeable objects in the EMF configuration properties (e.g.
JTA_PLATFORM, datasource, other stuff). In most cases, we will have a
session factory name (preferred) or persistence unit name to uniquely
identify the EntityManagerFactory. In 4.0.1, during serialization, we
only serialize the (hopefully) unique name.
If a duplicate EntityManagerFactory is created (by name), no immediate
error is given, instead we only give an error later when deserializing
the EMF. The HibernateException thrown during deserialization will look
like:
"registry contains more than one (" +
entityManagerFactorySet.size()+ ") entity manager factories: "
+ name
If that causes issues for any application, the SESSION_FACTORY_NAME can
be passed in from the troubled application (possibly with
SESSION_FACTORY_NAME_IS_JNDI set to false but true is also fine).
For the 4.1 release, I would like to take this one step further. The
above changes, only were made for EntityManager serialization of the EM
to EMF reference. The next step is to apply the same change to the EMF
readObject/writeObject, such that we also allow the EMF to be serialized
when it contains nonserializable objects. This also simplifies the EM
serialization, as it can just use default serialization for the EMF.
The proposed commit (to be fixed in 4.1) is at
https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55a7d9c90b7126c5a5ae2.
Feedback on the change is welcome (we are building 4.1 final middle of
this week).
Scott
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Forum not functional
Hi, it seems like something is wrong with the database of the Hibernate forum. Accessing https://forum.hibernate.org/ gives me only a MySQL error: General ErrorSQL ERROR [ mysql4 ] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) [2002] I don't know who's in charge for the forum, but maybe you guys do? --Gunnar ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
