H4 mapping xsd question
by Strong Liu
Hi,
I have two question about this xsd:
1. why we use xs:string for attributes such as timeout, batch-size, is there a specific reason?
I'm purposing this change https://gist.github.com/3059390
2. we used to have this with the dtd, but I doubt if it is still possible with in the current xsd. at least I could not find how to get this query text form org.hibernate.internal.jaxb.mapping.hbm.JaxbSqlQueryElement
not a xsd guy, can someone take a look?
<sql-query name="orgNamesOnly">
<return-scalar column="NAME" type="string"/>
SELECT org.NAME FROM ORGANIZATION org
</sql-query>
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
14 years
[Search] Lucene 4.0.0 Alpha is out
by Hardy Ferentschik
Hi,
here is a great post from Mike McCandless on what's going to change in Lucene 4 - http://goo.gl/blgGH
Quite a bit as Sanne already pointed out. A lot of things will be really useful for us, but given the overall
amount of changes our work to integrate Lucene 4 is also cut out.
--Hardy
14 years
Pull request for HHH-2394 (Support filter tag in subclass)
by Rob Worsnop
https://github.com/hibernate/hibernate-orm/pull/339
It seemed that the challenge to overcome was that Hibernate did not
know which aliases to use when generating the where clauses for
filters. When filters are not allowed on subclasses (current
situation), the alias for the root entity is used for all where
clauses. So when FilterHelper is asked to render the filters, it does
so with a single alias string.
So my changes revolve around two themes:
1. Remembering the filter's associated table so that we can generate
an appropriate alias. This was done by replacing the name->condition
map with a list of FilterConfiguration objects. This is a new class
and includes a qualified table name (as well as the name and
condition, of course).
2. Passing a callback (instead of the alias string) to
FilterHelper.render() that allows it to generate an appropriate alias
for each filter, depending on table name. The callback is an
implementation of a new interface, FilterAliasGenerator. The
implementation varies by context.
Where filters are applied to entities, we know the table name. When
filters are applied to collections we do not. My solution to this is
potentially controversial and I'd be interested in hearing
alternatives to it. I have expanded the @Filter annotation to include
a table name. This is an optional element because it makes no sense
when @Filter is applied directly to an entity. That's what I don't
like about this idea.
For example:
@OneToMany(mappedBy="club")
@Filters({
@Filter(name="iqMin", table="ZOOLOGY_HUMAN", condition="HUMAN_IQ >= :min"),
@Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
This is excerpted from here:
https://github.com/rworsnop/hibernate-orm/blob/HHH-2394/hibernate-core/sr...
Thoughts?
14 years
Ejb3Configuration
by Steve Ebersole
We all have agreed that Ejb3Configuration is a mess. In my JPA 2.1
branch I again decided to look at attacking that problem. So I came up
with the notion of an EntityManagerFactoryBuilder that takes the place
of Ejb3Configuration.
That code is all in place and all tests that use JPA boostrapping
through Persistence or PersistenceProvider are passing. I still have
not changed the base test classes that build an Ejb3Configuration as
means to bootstrap HEM, so I am not sure how much of that logic is
missing. The reason I stopped is that what I REALLY want to do is to
just rip out Ejb3Configuration. We deprecated it back in 4.0 for just
this purpose. We knew that we wanted to replace it and that
Ejb3Configuration would simply not work when we went to integrate
metamodel. EntityManagerFactoryBuilder is built to work with the new
metamodel code.
So bottom line, unless I hear compelling reason(s) not to, I plan on
removing Ejb3Configuration from the codebase. The sooner the better.
--
steve(a)hibernate.org
http://hibernate.org
14 years, 1 month
how to get an EntityBinding by class name?
by Strong Liu
Hi,
having a question as $subject.
the return element (org.hibernate.internal.jaxb.mapping.hbm.JaxbReturnElement) has both entity name and class name attributes, and we are supposed to use one of them to get the target EntityBinding.
though look up entitybinding by entityname is easy, but I'm not sure how to look up entitybinding by class name, for now, i have used a stupid way, iterator the whole entitybindings within Metadata
org.hibernate.metamodel.internal.source.annotations.global.SqlResultSetProcessor#bindEntityResult
wondering if there is a better way to deal with this.
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
14 years, 1 month
automated response
by richard
Hei,
jeg har sommerferie og er tilbake i jobb mandag 30. juli.
Generelle henvendelser kan sendes til post(a)hmskontoret.no. Du finner ytterligere informasjon om hvordan du kontakter HMS Kontoret i ferien her: www.hmskontoret.no.
God sommer!
14 years, 1 month
Re: [hibernate-dev] how to get an EntityBinding by class name?
by Hardy Ferentschik
On Jul 6, 2012, at 4:08 PM, Steve Ebersole wrote:
> We need JPA entity-name as a separate deal. There is a reason I added it ;)
Right. I know you keep saying this :-) It's just I have not seen this reason yet. I guess if I would dig deeper into the code
I would find it somewhere
> Its not the same as a Hibernate entity name. Nor is it the same as a Hibernate import name. It is something very specific.
14 years, 1 month
Re: [hibernate-dev] how to get an EntityBinding by class name?
by Steve Ebersole
>> In Hibernate you can map the same class multiple times using
>> different entity names. The map of entity bindings kept in Metadata
>> contains
>> all entity bindings keyed against these unique names. Trying to look
>> up a binding by class name is not unique and we would have to deal with
>> multiple bindings.
>>
>> >From a JPA perspective you cannot map a class multiple times. You
>> can give it an alternate name via @Entity#name, but that's about it
>> (names
>> must be unique within the persistence unit). If I am not mistaken atm
>> JPA entities are mapped in the entityBindingMap map using the
>> unqualified
>> class name (which is probably wrong).
That would be an error if that is true. They definitely should be
getting keyed by their entity-name (which in normal cases is the FQN of
the entity class).
>> In the source interfaces we have:
>>
>> EntitySource#getEntityName()
- this is the Hibernate notion of an entity name. In JPA this will
always be the same as the entity class name. In Hibernate this is the
entity name associated with this entity mapping. As Hardy points out
this can be multiple entity names pointing to the same entity class.
>> EntitySource#getClassName()
- this is the string representation of the entity class name (its
Class#getName). This can potentially be null eventually using
Hibernate notion of MAP entity mode, though we really have not
integrated that into the metamodel code as of yet.
>> EntitySource#getJpaEntityName() // taken from @Entity#name
- this is the JPA @Entity#name value as already pointed out. In HBM
cases this will be null.
>> Last but not least, looking at @EntityResult I can see that the
>> connection to the corresponding entity is made via a Class reference
>> (EntityResult#entityClass()), not
>> by name. I guess that's why you need to this in the lookup in the
>> first place. For this use case iterating seems fair enough for the
>> moment.
Any JPA API is going to deal with the @Entity Class reference. In
those cases the correct thing to do is to resolve that Class to
entity-name using Class#getName and do the lookup. If we want to
support something like @EntityResult with Hibernate-style entity-names
we will need to provide a another "alternate" (set of) annotation(s) to
accept the String entityName.
--
steve(a)hibernate.org
http://hibernate.org
14 years, 1 month
