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


Groups > comp.lang.java.programmer > #16181

Re: JDBC, PreparedStatement and named parameters

From Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Newsgroups comp.lang.java.programmer
Subject Re: JDBC, PreparedStatement and named parameters
Date 2012-07-21 14:32 +0000
Organization A noiseless patient Spider
Message-ID <slrnk0lfbm.u9l.avl@gamma.logic.tuwien.ac.at> (permalink)
References (5 earlier) <juc1g8$olu$1@dont-email.me> <slrnk0jhun.u9l.avl@gamma.logic.tuwien.ac.at> <juchjt$vsa$1@dont-email.me> <slrnk0jn8n.u9l.avl@gamma.logic.tuwien.ac.at> <jucodj$cd3$1@dont-email.me>

Show all headers | View raw


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.

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web