Interceptor and EntityTuplizer

[gavinking]

• Interceptor is one of the truly most ancient APIs in Hibernate, and I'm almost surprised it hasn't been deprecated and replaced yet. I suppose it must still be useful.
• EntityTuplizer is a deprecated interface, along with the rest of its hierarchy.

Both these user-visible APIs have the same problem: identifiers are typed as Serializable.

So what are we going to do with these things in 6?

1. Just change the types from Serializable to Object?
2. Add default methods that accept Object and deprecate the previous signatures?
3. Do nothing, but deprecate Interceptor?
4. Something else?

[beikov]

I'd prefer option 1. I think Interceptor is a useful API. Not sure about EntityTuplizer, but if it was deprecated for a long time already, I think it's time to let it go in 6.

[gavinking]

Not sure about EntityTuplizer, but if it was deprecated for a long time already, I think it's time to let it go in 6.

Ah, if it's already been deprecated for a long time then I agree. We should just remove it.

[beikov]

I just looked, but it is not. You were saying that initially though:

EntityTuplizer is a deprecated interface, along with the rest of its hierarchy.

[gavinking]

It's been deprecated in Hibernate six.

(Not in five.)

[sebersole]

Logically it should go away. Not sure yet if it can, for 2 reasons:

1. We'd need to make sure we've moved all calls to the "writing" aspects of the tuplizer contract to use the EntityRepresentationStrategy forms instead (6 only changes how reading works)
2. The "walking" model may use it as well. I have a separate task to remove that walking SPI

[gavinking]

Oh I see. I did not realize that it was still being used internally.

Well, if it's now for internal use, then we could make the change to Serializable, it seems to me.

[sebersole]

Everywhere I've simply changed Serializable to Object. I don't see any reason this should be different.

[gavinking]

Well I figured it was a change that breaks user code. But I’m very happy to do it anyway.

But what about Interceptor? That’s even more user-visible.

[sebersole]

Very few people (that I know of) implement any tuplizer. Its not an exposed API so I'm not too worried about people calling it either. One of my pre-Beta tasks is to remove the older loading stuff and will take a look at removing tuplizers then.

Interceptor is a bit different I agree. What I had done previously (that never got pushed as it was wrapped up in a PR that got too large) was to

1. deprecate the methods using Serializable as the id type
2. add overloaded method using Object with a default casting to Serialzable and calling the older one

IMO that's the best approach with Interceptor

[gavinking]

OK great. I agree. I will add the change to Tuplizer to my PR.

[gavinking]

Done.

[sebersole]

Nice. Did you change Interceptor as well?

[gavinking]

No, not yet.

[gavinking]

So if #3770 gets integrated, all that remains is Interceptor to think about.

[gavinking]

OK, Interceptor and Lifecycle have been migrated in a backward-compatible way.

EntityTuplizer has been migrated in a "breaking" way.

This is now resolved.