Steve,
out of interest, for which approach did you decide in the end?
--Gunnar
2012/11/20 Steve Ebersole <steve(a)hibernate.org>
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" <hardy(a)hibernate.org>
wrote:
>
> On 16 Jan 2012, at 4:34 PM, Steve Ebersole wrote:
>
> > The alternative would be something like defining a typed
> > RegisteredParameter contract:
> >
> > interface RegisteredParameter<T> {
> > public Class<T> getParameterType();
> > public ParameterMode getMode();
> > }
> >
> > and then:
> >
> > StoredProcedureCall call =
session.createStoredProcedureCall("my_proc");
> > RegisteredParameter<Long> p1Param = call.registerParameter(
> > "p1",
> > Long.class,
> > ParameterMode.OUT
> > );
> > //maybe some other stuff...
> > StoredProcedureOutputs outputs = call.getOutputs();
> > Long p1 = outputs.getOutputParameterValue( p1Param );
>
> I also like this second option better. Even though I don't think the
casts
> are so bad either. I find
> our days there is too much hype around type safety and in fact in some
> situation a cast can be "cleaner" than a
> whole bunch of generic classes and methods.
>
> I also like the approach with three parameters (name, type and mode)
> better than splitting this out into
> multiple methods. I actually don't think that the other approach is more
> readable.
>
> Last but not least I am not a big fan of the builder approach either ;-)
>
> My 0.02 $
> Hardy
>
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev