Is there any estimate what would be gained perf-wise by doing this optimization?
> First, this obviously is more fragile than relying on names; if the order
> changes but the bytecode is not re-enhanced, that could lead to very
> subtle, nasty problems.
Agreed, but to me it seems acceptable with
I have no estimate as to how much this would help. Many of the
improvements coming from the performance work have been of the sort that is
removing Map lookups; some of them across VERY small (and finite) sets of
Map keys. My concern here is that the Map look up occurs any time an
enhanced entity
But I think that just redefines the same problem. Just that now instead of
String->Integer we need some Integer->Integer resolution. Not sure that
really gains us anything.
On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole wrote:
> I have no estimate as to how much this would help. Many of the
>
On 11/12/2015 08:36 AM, Gunnar Morling wrote:
> Is there any estimate what would be gained perf-wise by doing this
> optimization?
>
>> First, this obviously is more fragile than relying on names; if the order
>> changes but the bytecode is not re-enhanced, that could lead to very
>> subtle, nast
It would be a one-time effort during persister initialisation; At that
time a look-up would happen in order to seed persisters with
attributes in the order as determined by the enhancer. Then at
runtime, upon getter/setter invocation, the index values passed from
the enhanced code would be used as
But see that is exactly the problem. That cannot work. You want us to
delay enhancement until after the persisters are built. But building the
persisters requires access to the Class. But by that time since we have
the Class reference we can no longer enhance it. It's a chicken-egg
problem.
W
> You want us to delay enhancement until after the persisters are built.
No, I mean to let enhancement define the attribute ordering and
initialize persisters with that previously defined order.
> What I suggest longer term is a slight variation...
Yes, that sounds nice.
2015-11-12 16:07 GMT+0
https://hibernate.atlassian.net/browse/HHH-10280
https://hibernate.atlassian.net/browse/HHH-10281
On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote:
> no objections
>
> On 11 November 2015 at 17:55, Steve Ebersole wrote:
>
>> I'd like to more formally deprecate the legacy bytecode enhanceme
+1
On 12 November 2015 at 16:39, Steve Ebersole wrote:
> https://hibernate.atlassian.net/browse/HHH-10280
> https://hibernate.atlassian.net/browse/HHH-10281
>
> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote:
>
>> no objections
>>
>> On 11 November 2015 at 17:55, Steve Ebersole wrote:
>>
Sounds like a very interesting patch, I agree with you that there's
much potential.
Although Steve from your description it seems like you don't think it can work?
I would expect something among the lines of what Gunnar described to
be feasible: to let the persisters figure out the right numbers w
On Thu, Nov 12, 2015 at 2:44 PM Sanne Grinovero wrote:
> Sounds like a very interesting patch, I agree with you that there's
> much potential.
> Although Steve from your description it seems like you don't think it can
> work?
>
Not sure I follow. You agree with the potential of the idea I am
p
Hey,
How would migration for a user look like?
Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
(assuming the old enhancer has been removed) be able to work with
entities enhanced by the old one, or would a re-build of the app be
required? Would they see a deprecation at all
12 matches
Mail list logo
