[OGM] OGM-21 query support
by Guillaume SCHEIBEL
Hello,
I have started to work on the support of the JPQL queries from the
EntityManager and I'm facing some difficulties.
I have look into the ORM as a start and so I have created
public class OgmQueryImpl<X> extends AbstractQueryImpl<X> implements
TypedQuery<X> { ... }
Therefore, the AbstractQueryImpl class needs a constuctor
using HibernateEntityManagerImplementor. Because OgmEntityManager is
directly implementing EntityManager it cannot be done directly (HEMI is an
implementation of the EntityManager interface).
So I've tried to switch OgmEntityManager to
extend AbstractEntityManagerImpl (which is an implementation of
HibernateEntityManagerImplementor) but now
OgmEntityManager#getEntityManagerFactory() must return an instance
of EntityManagerFactoryImpl.
The point is OgmEntityManagerFactory is implementing EntityManagerFactory
and HibernateEntityManagerFactory and not EntityManagerFactoryImpl.
I don't want to change the complete class hierarchie if there is a better
option / choice.
So any thoughts ?
Guillaume
10 years, 3 months
Object/Relational mapping XML processing moving forward
by Steve Ebersole
Reference :
https://hibernate.atlassian.net/browse/HHH-8893
https://hibernate.atlassian.net/browse/HHH-8894
I wanted to start a discussion around some planned changes relating to
processing XML mapping files. The 2 issues above cover the bulk of the
intent:
1) move to a single format for expressing object/relational mapping in
XML, based on the JPA ORM XSD
2) combine that with transformations for numerous known formats to a
definitive format for processing.
The basic idea here is to have just one XML format that we actually
process as input (StAX+JAXB). It would be a derivative of the latest
JPA ORM XSD ("extended" for Hibernate-specifics). We would still accept
numerous other forms (hbm.dtd, "straight" orm.xsd versions 1.0, 2.0,
2.1) and transform them to the "extended" schema. This transformation
would be available on-the-fly as well as via a build-time task.
This opens up the question of exactly how we want to mix the
Hibernate-specifics in with the JPA entity-mappings schema types. For
example we might want to take this opportunity to "clean up" the things
we expose via XML, or unify them. For now, I'd like to just make this
an open call for suggestions of things people would like to see changed
in XML mappings.
10 years, 3 months
Re: [hibernate-dev] merge on new entities
by Sanne Grinovero
Thanks!
yes we got to that conclusion. The question came from Radim in
Infinispan team attempting to figure out how to squeeze some more
performance from the JPACacheStore from Infinispan.
It's tricky that in Infinipan we don't know if something is a new
entry or an update; I had a highly customized MySQL CacheStore which
used the "INSERT OR UPDATE" statement, a non-standard feature from
that DB which is very useful for this case.
Could be interesting for Hibernate ORM to think of a JPA merge
implementation which could take advantage of such custom extensions?
Requires quite a different Dialect API.
Sanne
On 27 January 2014 09:07, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> If the id is assigned, we do a select first. Not super efficient but
> that's about the only thing you can do.
10 years, 3 months
Named Prepared Statements
by Igor Chubin
Hallo list,
I'm writing a Hibernate-dialect for a DBMS, and I can't understand
what is the best way to do some things.
One of my questions:
How can I configure in the dialect, that it must/must not use
named prepared statements.
For example, I have this in HQL:
Query query = session.createQuery("update Student set studentName = :studentName" + " where studentId = :studentId");
query.setParameter("studentName", "Jack");
query.setParameter("studentId", 1);
And in resulting SQL:
update tutorials.student set STUDENT_NAME=? where STUDENT_ID=?
Is it posible to use named prepared statements in the resulting SQL?
And opposite: how do I say that my DBMS doesn't support prepared
statements?
Thank you very much!
--
Igor Chubin
10 years, 3 months
New parser bugs reported: HQLPARSER vs HHH ?
by Sanne Grinovero
A forum user had some trouble with the current HQL parser:
https://forum.hibernate.org/viewtopic.php?f=1&t=1030515
And since I've been slow to react, he went ahead and created a JIRA; I
think he's right about this, still then - as you can see from his
latest post - he felt unsure on where to open it, and it became
HQLPARSER-35.
Since this is about the current parser, he's probably in the wrong
place, and there is a risk that the ORM team won't notice timely? but
I don't think I can blame him as it's probably confusing.
My first impulse was to jump on JIRA and see if I could enable some
big fat warning on HQLPARSER to explain the difference, but actually
maybe it's better if the ORM team could start looking at new issues in
there as _actual_ issues?
I'm thinking that while HQLPARSER matures, it should also incorporate
fixes/tests happening on the mainline parser: if there was a single
place to track defects of both I could "catch up" on ORM improvements
when working on it.
So... should I move HQLPARSER-35 to HHH, or shall we leave it there ?
Maybe better to duplicate the issues?
I'm voting for duplication, as they require either a fix or at least a
test applied to both projects, and we probably want to keep lifecycle
independent for a while longer.
Sanne
10 years, 3 months
