Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #16142 > unrolled thread

JDBC, PreparedStatement and named parameters

Started byAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
First post2012-07-20 09:39 +0000
Last post2012-07-21 21:53 -0400
Articles 20 on this page of 21 — 7 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-20 09:39 +0000
    Re: JDBC, PreparedStatement and named parameters markspace <-@.> - 2012-07-20 06:31 -0700
      Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-20 14:52 +0000
        Re: JDBC, PreparedStatement and named parameters markspace <-@.> - 2012-07-20 08:15 -0700
          Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-20 16:26 +0000
            Re: JDBC, PreparedStatement and named parameters markspace <-@.> - 2012-07-20 09:37 -0700
              Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-20 21:04 +0000
                Re: JDBC, PreparedStatement and named parameters markspace <-@.> - 2012-07-20 14:12 -0700
                  Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-20 22:35 +0000
                    Re: JDBC, PreparedStatement and named parameters markspace <-@.> - 2012-07-20 16:08 -0700
                      Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-21 14:32 +0000
                        Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-24 16:18 +0000
              Re: JDBC, PreparedStatement and named parameters Arne Vajhøj <arne@vajhoej.dk> - 2012-07-20 22:13 -0400
    Re: JDBC, PreparedStatement and named parameters Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-20 10:22 -0700
      Re: JDBC, PreparedStatement and named parameters Lew <lewbloch@gmail.com> - 2012-07-20 11:00 -0700
    Re: JDBC, PreparedStatement and named parameters Arne Vajhøj <arne@vajhoej.dk> - 2012-07-20 22:11 -0400
      Re: JDBC, PreparedStatement and named parameters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-07-21 14:47 +0000
        Re: JDBC, PreparedStatement and named parameters jebblue <n@n.nnn> - 2012-07-23 22:14 -0500
          Re: JDBC, PreparedStatement and named parameters jebblue <n@n.nnn> - 2012-07-23 22:19 -0500
    Re: JDBC, PreparedStatement and named parameters Roedy Green <see_website@mindprod.com.invalid> - 2012-07-21 15:00 -0700
      Re: JDBC, PreparedStatement and named parameters Arne Vajhøj <arne@vajhoej.dk> - 2012-07-21 21:53 -0400

Page 1 of 2  [1] 2  Next page →


#16142 — JDBC, PreparedStatement and named parameters

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-20 09:39 +0000
SubjectJDBC, PreparedStatement and named parameters
Message-ID<slrnk0i9rb.u9l.avl@gamma.logic.tuwien.ac.at>
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?

[toc] | [next] | [standalone]


#16145

Frommarkspace <-@.>
Date2012-07-20 06:31 -0700
Message-ID<jubmj6$ip8$1@dont-email.me>
In reply to#16142
On 7/20/2012 2:39 AM, Andreas Leitgeb wrote:
>
> 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/>

[toc] | [prev] | [next] | [standalone]


#16148

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-20 14:52 +0000
Message-ID<slrnk0is4j.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16145
markspace <-@> wrote:
> On 7/20/2012 2:39 AM, Andreas Leitgeb wrote:
>> 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/>

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?

[toc] | [prev] | [next] | [standalone]


#16151

Frommarkspace <-@.>
Date2012-07-20 08:15 -0700
Message-ID<jubsm4$o36$1@dont-email.me>
In reply to#16148
On 7/20/2012 7:52 AM, Andreas Leitgeb wrote:

> 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?


[toc] | [prev] | [next] | [standalone]


#16154

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-20 16:26 +0000
Message-ID<slrnk0j1lf.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16151
markspace <-@> wrote:
> On 7/20/2012 7:52 AM, Andreas Leitgeb wrote:
>> 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.

Thanks for trying to help, anyway.

[toc] | [prev] | [next] | [standalone]


#16155

Frommarkspace <-@.>
Date2012-07-20 09:37 -0700
Message-ID<juc1g8$olu$1@dont-email.me>
In reply to#16154
On 7/20/2012 9:26 AM, Andreas Leitgeb wrote:
> markspace <-@> wrote:
>> On 7/20/2012 7:52 AM, Andreas Leitgeb wrote:
>>> 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.
>
> 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".




[toc] | [prev] | [next] | [standalone]


#16163

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-20 21:04 +0000
Message-ID<slrnk0jhun.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16155
markspace <-@> wrote:
> On 7/20/2012 9:26 AM, Andreas Leitgeb wrote:
>> 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.

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.

[toc] | [prev] | [next] | [standalone]


#16164

Frommarkspace <-@.>
Date2012-07-20 14:12 -0700
Message-ID<juchjt$vsa$1@dont-email.me>
In reply to#16163
On 7/20/2012 2:04 PM, Andreas Leitgeb wrote:
> markspace <-@> wrote:
>> On 7/20/2012 9:26 AM, Andreas Leitgeb wrote:
>>> 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.
>
> 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?

[toc] | [prev] | [next] | [standalone]


#16167

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-20 22:35 +0000
Message-ID<slrnk0jn8n.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16164
markspace <-@> wrote:
> On 7/20/2012 2:04 PM, Andreas Leitgeb wrote:
>> markspace <-@> wrote:
>>> On 7/20/2012 9:26 AM, Andreas Leitgeb wrote:
>>>> 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.
>> 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?

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.

[toc] | [prev] | [next] | [standalone]


#16168

Frommarkspace <-@.>
Date2012-07-20 16:08 -0700
Message-ID<jucodj$cd3$1@dont-email.me>
In reply to#16167
On 7/20/2012 3:35 PM, Andreas Leitgeb wrote:
>
> 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?

[toc] | [prev] | [next] | [standalone]


#16181

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-21 14:32 +0000
Message-ID<slrnk0lfbm.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16168
markspace <-@> wrote:
> On 7/20/2012 3:35 PM, Andreas Leitgeb wrote:
>> 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. ;)

:-)

> Not posting "solutions" because you asked that none be posted....
Thanks. (Yeah, I really meant it so.)

>> 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.

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.

[toc] | [prev] | [next] | [standalone]


#16304

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-24 16:18 +0000
Message-ID<slrnk0timj.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16181
Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> 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.

-- 
Ceterum censeo, "named parameters" esse "cool feature."  :-)

[toc] | [prev] | [next] | [standalone]


#16174

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-07-20 22:13 -0400
Message-ID<500a1048$0$292$14726298@news.sunsite.dk>
In reply to#16155
On 7/20/2012 12:37 PM, markspace wrote:
> On 7/20/2012 9:26 AM, Andreas Leitgeb wrote:
>> markspace <-@> wrote:
>>> On 7/20/2012 7:52 AM, Andreas Leitgeb wrote:
>>>> 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.
>>
>> 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.

> 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

[toc] | [prev] | [next] | [standalone]


#16158

FromDaniel Pitts <newsgroup.nospam@virtualinfinity.net>
Date2012-07-20 10:22 -0700
Message-ID<PtgOr.71$Mv7.19@newsfe12.iad>
In reply to#16142
On 7/20/12 2:39 AM, Andreas Leitgeb wrote:
> 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.


[toc] | [prev] | [next] | [standalone]


#16160

FromLew <lewbloch@gmail.com>
Date2012-07-20 11:00 -0700
Message-ID<5dbaba81-9aab-4268-a3b0-030fb3686886@googlegroups.com>
In reply to#16158
Daniel Pitts wrote:
> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]


#16173

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-07-20 22:11 -0400
Message-ID<500a0fcb$0$292$14726298@news.sunsite.dk>
In reply to#16142
On 7/20/2012 5:39 AM, Andreas Leitgeb wrote:
> 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


[toc] | [prev] | [next] | [standalone]


#16182

FromAndreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Date2012-07-21 14:47 +0000
Message-ID<slrnk0lg7u.u9l.avl@gamma.logic.tuwien.ac.at>
In reply to#16173
Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/20/2012 5:39 AM, Andreas Leitgeb wrote:
>> 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...

> 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 :-)

[toc] | [prev] | [next] | [standalone]


#16294

Fromjebblue <n@n.nnn>
Date2012-07-23 22:14 -0500
Message-ID<AaOdnbdNWO6XjpPNnZ2dnUVZ_sadnZ2d@giganews.com>
In reply to#16182
On Sat, 21 Jul 2012 14:47:26 +0000, Andreas Leitgeb wrote:

> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/20/2012 5:39 AM, Andreas Leitgeb wrote:
>>> 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...
> 
>> 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 :-)

Not in standard JDBC? java.sql.PreparedStatement.

[toc] | [prev] | [next] | [standalone]


#16295

Fromjebblue <n@n.nnn>
Date2012-07-23 22:19 -0500
Message-ID<AaOdnbZNWO6riZPNnZ2dnUVZ_sadnZ2d@giganews.com>
In reply to#16294
On Mon, 23 Jul 2012 22:14:18 -0500, jebblue wrote:

> On Sat, 21 Jul 2012 14:47:26 +0000, Andreas Leitgeb wrote:
> 
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 7/20/2012 5:39 AM, Andreas Leitgeb wrote:
>>>> 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
>>>>
> 
> Not in standard JDBC? java.sql.PreparedStatement.

Disregard, you're asking for named parameters like in Hibernate which
is where I've been using them; sorry.

[toc] | [prev] | [next] | [standalone]


#16200

FromRoedy Green <see_website@mindprod.com.invalid>
Date2012-07-21 15:00 -0700
Message-ID<jg9m08dcdodlslvblde3t6mmrm38mou68o@4ax.com>
In reply to#16142
On Fri, 20 Jul 2012 09:39:55 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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)
http://www.youtube.com/watch?v=F-QA2rkpBSY

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer


csiph-web