Sorry for late reply.
Well you mentioned Java 8 parameters names in the subject. I have no idea
what "Java 8 parameter names" might mean outside of the
support added in
Java 8 for named parameter binding. So if that's not what you mean, what
do you mean?
Based on some of your other replies, perhaps you are confusing "parameter
names" (PreparedStatement) and "column names" (ResultSet)?
I mean the Java 8 Parameter Names API -
https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterref...
.
So the basic idea is, if you know to which fields to inject the value, you
also know into which parameter the value should be injected.
I must say I'm not familiar with Hibernate ORM codebase so any clues where
to start looking would be helpful. Right now I'm searching for usages of
Class#newInstance and starting from there.
On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic(a)gmail.com>
> wrote:
>
>> I am confused how you are "mind mapping" PreparedStatement parameters
>>> and entity construction into the same conversation. We are not
>>> instantiating entities based on PreparedStatement parameters....
>>>
>>
>> I'm not sure I understand you, I haven't mentioned PreparedStatement
>> parameters anywhere.
>>
>
> Well you mentioned Java 8 parameters names in the subject. I have no idea
what "Java 8 parameter names" might mean outside of the
support added in
Java 8 for named parameter binding. So if that's not what you mean, what
do you mean?
Based on some of your other replies, perhaps you are confusing "parameter
names" (PreparedStatement) and "column names" (ResultSet)?
>
> What you propose is to delay the entity instantiation and create the
>>> entity instance from after we have the hydrated state.
>>
>>
>> Yes, the requirement for this to work is that before calling constructor
>> you have all arguments and target parameter names available.
>>
>
> Right, which precludes lazy loading; which is my point on the Jira.
>