JDBC, PreparedStatement and named parameters

[Andreas Leitgeb]

I'm rather new to JDBC, and somewhat experienced with
database access in other languages, like with ProC or
with the sqlplus-shell.

While in C/C++ eSql with ProC (not sure about correct
nomenclature) I can use named variables for the parameters,
jdbc seems like it would only allow positional parameters.

With Google, I stumbled over this approach:

http://www.javaworld.com/javaworld/jw-04-2007/jw-04-jdbc.html

which boils down to pre-processing the sql-statement, replacing
the named variables by "?" while creating an array of the parameters
such, that e.g. a snippet like this:
"... :a :c :b :a ..." and setting a -> x1, b -> x2, c -> x3
would turn into
"... ? ? ? ? ..." with an parameter array of { x1, x3, x2, x1 }

That almost looks like what I was hoping for, but when I see
that the article is 5 years old, then I'd hope that something
similar might meanwhile have been turned into a standard...

Does anyone here know of a way to use either named variables,
or at least something like these "foo {1} bar {0}" things
used in jsf4j and java.text.MessageFormat?

 

[markspace]

Does anyone here know of a way to use either named variables,
or at least something like these "foo {1} bar {0}" things
used in jsf4j and java.text.MessageFormat?

Well, JPA obviously, but have you looked at any database frameworks or
helpers at all?


<http://commons.apache.org/dbutils/>

 

[Andreas Leitgeb]

Well, JPA obviously, but have you looked at any database frameworks or
helpers at all?
<http://commons.apache.org/dbutils/>

The DbUtils examples all seem to use "?", so I wonder, if
this DbUtils really can do more, or if it was just a quick-shot
answer.

My question was a bit more specific than just about how to use
parameters at all. Rather, it was about how to de-couple the
exact shape of the where-clause from the array of parameters
that provides the variable parts.

Now, do Apache DbUtils really address this?

 

[markspace]

My question was a bit more specific than just about how to use
parameters at all. Rather, it was about how to de-couple the
exact shape of the where-clause from the array of parameters
that provides the variable parts.

Now, do Apache DbUtils really address this?

I don't understand the word "shape" when applied to parsing, databases,
or Java. I think perhaps you need to think about what your actual
requirements are.

I also mentioned JPA. How does that work for you?

 

[Andreas Leitgeb]

I don't understand the word "shape" when applied to parsing, databases,
or Java.

Thanks for trying to help, anyway.

 

[markspace]

Thanks for trying to help, anyway.

Here's a hint: when you post asking for help making something work like
<insert non-Java system here>, most of us are going to have no idea what
you are really asking for.

Personally, the more I think about it, the more I think having a second
layer of binding that you have to deal with is going to be a bigger pita
than just using indexes. That jdbcUtils package I pointed you at made
it very easy to do that, if you'd bothered to read the documentation
further than just noticing the question marks in the SQL statements.

I've had MyBatis recommended to me when I asked a similar question. I
haven't looked at it, but a quick review of their user guide looks like
it has some sort of bindings available by name/property.

Stuff is out there, but "works like X" isn't going to help anyone who
isn't familiar with X. I certainly can't read your mind, or develop
requirements just by staring at the word "X".

 

[Daniel Pitts]

I'm rather new to JDBC, and somewhat experienced with
database access in other languages, like with ProC or
with the sqlplus-shell.

While in C/C++ eSql with ProC (not sure about correct
nomenclature) I can use named variables for the parameters,
jdbc seems like it would only allow positional parameters.

With Google, I stumbled over this approach:

http://www.javaworld.com/javaworld/jw-04-2007/jw-04-jdbc.html

which boils down to pre-processing the sql-statement, replacing
the named variables by "?" while creating an array of the parameters
such, that e.g. a snippet like this:
"... :a :c :b :a ..." and setting a -> x1, b -> x2, c -> x3
would turn into
"... ? ? ? ? ..." with an parameter array of { x1, x3, x2, x1 }

That almost looks like what I was hoping for, but when I see
that the article is 5 years old, then I'd hope that something
similar might meanwhile have been turned into a standard...

Does anyone here know of a way to use either named variables,
or at least something like these "foo {1} bar {0}" things
used in jsf4j and java.text.MessageFormat?

Depending on your needs, a JPA provider (such as Hibernate) may be a
better approach. It moves you away from low-level SQL, and into more
object oriented notation.

It isn't always the best solution, and my experience with Hibernate has
been mixed. It's worth looking into and learning about it. They tend
to be useful if you do exactly what they were designed for, and then
they get in your way when you need to do something different.

 

[Lew]

Depending on your needs, a JPA provider (such as Hibernate) may be a

A word to the wise: if you do use Hibernate itself, as opposed to, say,
Apache OpenJPA or EclipseLink, make sure you use it as a JPA framework,
and not as old-style Hibernate.

better approach. It moves you away from low-level SQL, and into more
object oriented notation.

For certain values of "better".

It is often better to use raw JDBC.

You can more or less fake out named parameters with a combination of
java.sql.PreparedStatement and an enum for the indexes.

JPA has its own query language that directly supports named parameters.

It isn't always the best solution, and my experience with Hibernate has
been mixed. It's worth looking into and learning about it. They tend

Hibernate is fine if you restrict yourself to the newer JPA approach.

EclipseLink and OpenJPA know no other way.

Keep your EntityManagers short-lived and don't share them across threads.

Keep your EntityManagerFactory long-lived, and IIRC it's shareable.

You have to use JPA in an idiomatically Java way to get its full value.

to be useful if you do exactly what they were designed for, and then
they get in your way when you need to do something different.

The use case for raw JDBC is bulk operations.

For object-to-relational mapping the JPA ORM frameworks are great.

Don't get too fancy with your JPA.

 

[Andreas Leitgeb]

Here's a hint: when you post asking for help making something work like
<insert non-Java system here>, most of us are going to have no idea what
you are really asking for.

The answers I got did indicate to me that the feature I wanted
is just not as common and near hand (to my hand, that is), as I'd
hoped it would be.

 

[markspace]

The answers I got did indicate to me that the feature I wanted
is just not as common and near hand (to my hand, that is), as I'd
hoped it would be.

I still wish you'd be a little more forthcoming about what it is you are
looking here. At least half the reason I post answers here is so that I
also can learn things. What is so great about this eSql and ProC that
you'd hope to find it in a Java library?

 

[Andreas Leitgeb]

I still wish you'd be a little more forthcoming about what it is you are
looking here. At least half the reason I post answers here is so that I
also can learn things. What is so great about this eSql and ProC that
you'd hope to find it in a Java library?

Here's a slight simplification of my problem at hand:
(I'm *NOT* asking for a solution nor even for help to this
problem - Unlike the Jdbc-question which I originally posted,
this one's not even related to Java.)

I have a somewhat convoluted sql-problem at hand. Two tables are joined,
just not by a single join-column, but by overlapping intervals.

Table1: from1, to1
Table2: from2, to2
Params: from3, to3

I have to identify the intersections of the table's intervals
within the bounds of a third interval given as parameter.
I figured it would take me quite a couple of tries to find which
variant of conjunctive inequalities would actually work best,
and the params from3 and to3 would not only change their relative
position often between consecutive trials, but will likely turn
out to be used multiple times, each, in the query.

With named parameters I could concentrate on the ordering of all
the single "fromX < toY"-terms.

As it is in jdbc, I'm instead facing a lot of "fromX < ?" and
"toY < ?" terms as well as a hard time trying to memorize which
of all the "?" was really meant to mean which of the params.

(I didn't really solve it, yet, but postponed it a bit for now.
Well, I do have such a clause now, that seems to work with simple
demo-data, but it sure as hell will come back on me. ;-) )

Again, I'm *NOT* asking for a solution nor even for help to the
intervals-problem - Unlike the Jdbc-question, it's not even
related to Java. I only mentioned it in answer to markspace's
curiosity.

 

[markspace]

Here's a slight simplification of my problem at hand:
(I'm *NOT* asking for a solution nor even for help to this

Yeah but it's an interesting problem.

problem - Unlike the Jdbc-question which I originally posted,
this one's not even related to Java.)

I have a somewhat convoluted sql-problem at hand. Two tables are joined,
just not by a single join-column, but by overlapping intervals.

Table1: from1, to1
Table2: from2, to2
Params: from3, to3

I think I did something similar once, although there was no join
involved. Intersection isn't really hard, but if you have a lot of
intervals to search it might be useful to look hard for an efficient
solution.

Not posting "solutions" because you asked that none be posted....

I have to identify the intersections of the table's intervals
within the bounds of a third interval given as parameter.
I figured it would take me quite a couple of tries to find which
variant of conjunctive inequalities would actually work best,

I'm going to have to look those words up.

and the params from3 and to3 would not only change their relative
position often between consecutive trials, but will likely turn
out to be used multiple times, each, in the query.

With named parameters I could concentrate on the ordering of all
the single "fromX < toY"-terms.

As it is in jdbc, I'm instead facing a lot of "fromX < ?" and
"toY < ?" terms as well as a hard time trying to memorize which
of all the "?" was really meant to mean which of the params.

In a pinch, string substitution might work.

long start = ...
long end = ...
String sql = "Select * from SomeTable where from >= ::start:: & to <=
::end::";
sql = sql.replaceAll( "::start::", Long.toString( start ) );
sql = sql.replaceAll( "::end::", Long.toString( end ) );

Cheesy, but it's "clear" what is being done.


Hmm, final thoughts... you have two tables joined on an *interval*?
That doesn't seem right. Time, or length, is continuous. Normally you
wouldn't expect the *exact* same values to appear in two places. Are
you sure this spec is correct?

 

[Arne Vajhøj]

I'm rather new to JDBC, and somewhat experienced with
database access in other languages, like with ProC or
with the sqlplus-shell.

While in C/C++ eSql with ProC (not sure about correct
nomenclature) I can use named variables for the parameters,
jdbc seems like it would only allow positional parameters.

With Google, I stumbled over this approach:

http://www.javaworld.com/javaworld/jw-04-2007/jw-04-jdbc.html

which boils down to pre-processing the sql-statement, replacing
the named variables by "?" while creating an array of the parameters
such, that e.g. a snippet like this:
"... :a :c :b :a ..." and setting a -> x1, b -> x2, c -> x3
would turn into
"... ? ? ? ? ..." with an parameter array of { x1, x3, x2, x1 }

That almost looks like what I was hoping for, but when I see
that the article is 5 years old, then I'd hope that something
similar might meanwhile have been turned into a standard...

Does anyone here know of a way to use either named variables,
or at least something like these "foo {1} bar {0}" things
used in jsf4j and java.text.MessageFormat?

JDBC is designed to support all databases.

The only JDBC driver shipping with JDK was the ODBC-JDBC
brudge.

ODBC only support named parameters for SP calls not
for regular SQL statements.

Possibly other database API's does not support it either.

So JDBC does not support named parameters.

You can obviously do the string manipulation stuff and
maybe wrap it nicely. But I assume you do not need help
with that.

Arne

 

[Arne Vajhøj]

Here's a hint: when you post asking for help making something work like
<insert non-Java system here>, most of us are going to have no idea what
you are really asking for.

Stuff is out there, but "works like X" isn't going to help anyone who
isn't familiar with X. I certainly can't read your mind, or develop
requirements just by staring at the word "X".

Actually his original post contained a code snippet of what he
want.

It just well hidden in the text.

Arne

 

[Andreas Leitgeb]

Yeah but it's an interesting problem.


Not posting "solutions" because you asked that none be posted....

Thanks. (Yeah, I really meant it so.)

I'm going to have to look those words up.

inequalities: something like "from1 < to2" (this is also a term)
"conjunctive" terms are terms joined with an " and ".

If you insist that "conjunctive xyz" would necessarily mean, that
the xyz itself be "conjunctive", rather than in a "conjunctive"
relationship with other xyzs, then that's fine with me, too.

In a pinch, string substitution might work.
long start = ... , end = ...
String sql = "... where from >= ::start:: & to <= ::end::";
sql = sql.replaceAll( "::start::", Long.toString( start ) );
sql = sql.replaceAll( "::end::", Long.toString( end ) );
Cheesy, but it's "clear" what is being done.

It's no longer a PreparedStatement, then, if I substitute the values
into the query. The cited(in the OP) webpage was a bit more fancy:
it replaced the names by question marks, and created an appropriate
Object[] in the process. I'll likely write such a processor, myself,
once I really need it.

Hmm, final thoughts... you have two tables joined on an *interval*?
That doesn't seem right. Time, or length, is continuous. Normally you
wouldn't expect the *exact* same values to appear in two places. Are
you sure this spec is correct?

The value domain behind the intervals is kind of continuous (well,
except for practical limitations). That's the point. That's why
it is not about identical intervals or even identical values. The
exact comparison between interval-corners is more of a threshold-
check. ... and did I say, that this example is already simplified?

Finally, I agree that the spec is not what I'd have called perfect.
Where table2 gets filled, some bit of information from table1 is
readily available, and storing it into an redundant extra column
of table2 would have saved me all these worries.

Nevertheless, I think that named parameters in prepared statements
would have been a good idea, even if it weren't for that one problem.

 

[Andreas Leitgeb]

JDBC is designed to support all databases.

The only JDBC driver shipping with JDK was the ODBC-JDBC
brudge.

ODBC only support named parameters for SP calls not
for regular SQL statements.

Possibly other database API's does not support it either.

Thanks. That explains, why this feature isn't standard in JDBC.
Since this new Java-project is meant to work with any jdbc-
supported DB, Oracle-extensions are a not an option here.

I must admit, that my C/C++ database background is entirely
limited to Oracle, but that's a different story.

You can obviously do the string manipulation stuff and
maybe wrap it nicely. But I assume you do not need help
with that.

Indeed

 

[Roedy Green]

I'm rather new to JDBC, and somewhat experienced with
database access in other languages, like with ProC or
with the sqlplus-shell.

see http://mindprod.com/jgloss/hibernate.html
http://mindprod.com/jgloss/jpa.html

If you look at the job ads, this is what employers want you to know.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)

 

[Arne Vajhøj]

see http://mindprod.com/jgloss/hibernate.html
http://mindprod.com/jgloss/jpa.html

You did not read the thread?

If you look at the job ads, this is what employers want you to know.

I think most employers want people that know these *and* know when
and how not to use those.

Arne

 

[Andreas Leitgeb]

Finally, I agree that the spec is not what I'd have called perfect.
Where table2 gets filled, some bit of information from table1 is
readily available, and storing it into an redundant extra column
of table2 would have saved me all these worries.

Finally, this point dissolves into happiness. Table2 gets that extra
column, so I won't really have to deal with that ugly interval-join.