Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #16181
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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