This fell through the cracks.
Emmanuel or Steve, please provide some feedback.
Thanks,
Gail
On Wed, Oct 26, 2016 at 6:48 AM, Gail Badner wrote:
> HHH-11144 involves an entity that has 2 one-to-many associations with the
> same type of entity, and both associations have orphanRemoval = true.
>
Hi all,
I'm soon going to rename branches on the reference repository
[https://github.com/hibernate/hibernate-search]
"master" branch is going to be renamed "5.6"
"5.7" branch is going to be renamed "master"
If you keep this in mind, you should be able to avoid any trouble:
rebase as usual bef
Hi,
Related to your questions:
he main thing I wonder about is what we mean by "custom
> types" in terms of what exactly is being customized? And how does that
> relate specifically to BasicType versus EmbeddedType versus ...?
Most of the time, the users want to take advantage of various datab
Right, and that exactly lines up with what I am proposing.
If the intent of "customize" is to describe new Java types (e.g. Java 8
temporals prior to our explicit support) the tht is the role of a
JavaTypeDescriptor, specifically a BasicJavaDescriptor. They would
register a BasicJavaDescriptor de
Hi,
I like the SqlTypeDescriptor and JavaTypeDescriptor much better than
UserType, which we should probably deprecate in 6.0.
I wrote an article on my blog in which I demonstrate how to create a JSON
type using JavaTypeDescriptor and SqlTypeDescriptor:
https://vladmihalcea.com/2016/06/20/how-to-
Nice!
So if we keep UserType, we have to be clear that it has to change. I also
do not want to continue to support the other "user type extensions", like:
1. org.hibernate.usertype.EnhancedUserType
2. org.hibernate.usertype.DynamicParameterizedType
3. org.hibernate.usertype.LoggableUse
Hi,
I see no reason why we should keep it indefinitely. I'd say we deprecate it
in 5.x, and remove it later (6.0 or 6.1).
Migrating a custom UserType to using Java and SQL descriptor is not
difficult, and we could just write a blog post for a step-by-step guide.
Anyone in favor of keeping UserTyp
trying to find a valid reason to keep UserType but not able, so I'm for
removing it.
On 23 January 2017 at 14:36, Vlad Mihalcea wrote:
> Hi,
>
> I see no reason why we should keep it indefinitely. I'd say we deprecate it
> in 5.x, and remove it later (6.0 or 6.1).
> Migrating a custom UserType t
Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used
instead, I'm also for removing it.
Am 23.01.2017 um 15:45 schrieb andrea boriero:
> trying to find a valid reason to keep UserType but not able, so I'm for
> removing it.
>
> On 23 January 2017 at 14:36, Vlad Mihalcea wrote:
>
>
What is everyone's opinion of the following sections?
There are some things we should discuss too in terms of user impact. We
know up front that we need to move to reading values from JDBC ResultSets
positionally, as opposed to nominally which is how it was exposed in
Hibernate prior to 6.0. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Following up on the thread from November [1], I'd really like to have a
decision made on this topic.
To recap, I'm requesting that my PR [2] be reviewed and, with any
suggested changes made, merged. to add an adapter to Hibernate allowing
it to use
11 matches
Mail list logo