I have not gone back to work on that yet. Been waiting to see how a
new propsal for JPA 2.1 that came out of the blue plays out before I
start playing with that code again.
On Fri 30 Nov 2012 08:20:05 AM CST, Gunnar Morling wrote:
> Steve,
>
> out of interest, for which approach did you decide
Steve,
out of interest, for which approach did you decide in the end?
--Gunnar
2012/11/20 Steve Ebersole
> Forgot to mention that there is a "named" component to this discussion as
> well in that users can specify named stored procedure queries. So we will
> need some form of simple access t
Forgot to mention that there is a "named" component to this discussion as
well in that users can specify named stored procedure queries. So we will
need some form of simple access to the parameters for setting.
On Nov 17, 2012 8:38 AM, "Hardy Ferentschik" wrote:
>
> On 16 Jan 2012, at 4:34 PM, S
On 16 Jan 2012, at 4:34 PM, Steve Ebersole wrote:
> The alternative would be something like defining a typed
> RegisteredParameter contract:
>
> interface RegisteredParameter {
> public Class getParameterType();
> public ParameterMode getMode();
> }
>
> and then:
>
> StoredProcedureCa
Hi,
I see two advantages of the approach using strongly typed parameter objects:
* I as a user don't need to do a cast when retrieving the value from an
output parameter. This avoids having to specify the type twice (once when
registering the parameter, once when retrieving the value) and it avoi
I dislike static builders. If we were going to go that route, I'd
rather see contextual builders:
StoredProcedureCall call = session.createStoredProcedureCall("my_proc");
OutParameter p1Param =
call.parameterRegistrar().out(Long.class).named("p1");
However, this still assumes that these "specia
Right, that's what I had in mind.
Another option would be a more builder-like approach:
StoredProcedureCall call = session.createStoredProcedureCall("my_proc");
OutParameter p1Param =
RegisteredParameter.outParameter(Long.class).named("p1Param");
InParameter p2Param =
RegisteredParameter.inParam
Again I am not so sure that registerInParameter is any more readable
than registerParameter passed ParameterMode.IN. Registering a
parameter is registering a parameter is registering a parameter to
para-quote Ms Stein. To me the one thing that would make sense to
split them out that way is what I
IMO registerInParameter(String,Class) et al. read better than
registerParameter(int,Class,ParameterMode), while the latter might be a bit
simpler to use when writing the code. As code is more read than written,
optimizing the read use case might be the better option. But I agree that
six methods co
I can definitely see a benefit to your registerOutParameter over
registerParameter if we wanted to return specific types. But aside
from that, I am not so sure that having to know 3 different sets of
methods to register parameters:
registerInParameter(int,Class)
registerInParameter(String,Class)
Hi,
FWIW, I'd prefer option #2 due to its type-safety. In #3 it's as you say
challenging to control when extract() can be invoked.
Maybe you could offer dedicated methods for the different parameter modes,
making client code a bit shorter:
RegisteredParameter p1Param =
call.registerOutParameter(
I thought I had written about this before to the list, but maybe not.
Anyway, I added much enhanced support for calling database functions and
procedures to master. But this is just my initial swag and as far as I
know my eyes are the only ones that have seen it. So I wanted to get
some feedb
12 matches
Mail list logo
