Hi Steve,
Let me clarify the first two questions:
I’m looking for an entry point/hook in H5 for altering existing class mappings.
For example; some of our entities are supposed to be immutable, but only in
production mode.
When running our tests we are using that same model to setup data
There is a migration guide:
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.
It is still a work in progress as in its is not "prettified" yet (as 5.0 is
not final yet. If things are missing please let us know.
Some answers inline...
- In Hibernate4 we modif
Hi Gunnar,
> Should we consider to drop this feature in HS 6?
-1, we use it, I think, in at least 3 places in our application.
Removing it would make our code more complicated.
Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@
Hi,
I'm migrating from Hibernate4 to 5(RC4). While doing so I'm stumbling on
some stuff that has been removed or moved.
- In Hibernate4 we modified mappings on-the-fly by overriding Spring's
LocalSessionFactoryBean#buildSessionFactory.
Doing so we could first access the getClassMapping on
That's an interesting proposal, as index sharing inherently implies
that fields on different types shall not have conflicting mapping
(i.e. don't reuse the same field name for a different type).
By default we don't share indexes across unrelated types, but also *by
default* subtypes are indexed in
Hi,
I guess it's useful in some edge cases where the user wants to search
different entities with one query. As long as everything is in the same index
scoring is a lot easier (I don't know if it even works otherwise). I guess
that could be done by indexing a common supertype, but sometimes that'
Hibernate Search aficionados,
I am wondering what that's the rationale for offering the feature of
index sharing [1].
The ref guide says "there is really not much benefit in sharing
indexes". It complicates queries, as an additional filter on the type
field must be applied in case of targeting on
