Maybe a bit late for this time, but might help next time:
history of moved files is still in CVS at their original location, see
cvs -d<user>@monetdb.cvs.sourceforge.net:/cvsroot/monetdb rlog -N
clients/src/java/src/nl/cwi/monetdb/jdbc/MonetConnection.java
Stefan
On Wed, Feb 20, 2008 at 07:50:26PM +0000, Fabian wrote:
> Update of /cvsroot/monetdb/java/src/nl/cwi/monetdb/jdbc
> In directory
> sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv12362/src/nl/cwi/monetdb/jdbc
>
> Modified Files:
> MonetConnection.java
> Log Message:
> Fix for bug #1886326:
> MonetDB JDBC driver exception for XQuery with no results
>
> 2 and a half hour later ...
> Due to missing history (cvs moves) and missing documentation (on my
> end) it took quite some while to figure out what was the "correct" way
> to solve this bug. In the end it al boiled down on the limitation of
> the XQuery backend to only support full-results-at-once, which means the
> resource allocation of JDBC needs to allocate the entire result at once.
> If the result is 0 rows big, however, then things went wrong when
> calculating the current cache block. Anyway, for the future we now know
> why we did this cache block calulation thing like this again...
>
>
>
> Index: MonetConnection.java
> ===================================================================
> RCS file: /cvsroot/monetdb/java/src/nl/cwi/monetdb/jdbc/MonetConnection.java,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -d -r1.2 -r1.3
> --- MonetConnection.java 11 Jan 2008 10:36:16 -0000 1.2
> +++ MonetConnection.java 20 Feb 2008 19:50:24 -0000 1.3
> @@ -1164,7 +1164,17 @@
> isSet = new boolean[7];
> this.parent = parent;
> if (parent.cachesize == 0) {
> - cacheSize = lang == LANG_SQL ?
> MonetConnection.DEF_FETCHSIZE : tuplecount;
> + /* Below we have to calculate how many "chunks"
> we need
> + * to allocate to store the entire result.
> However, if
> + * the user didn't set a cache size, as in this
> case, we
> + * need to stick to our defaults. So far, so
> good. Now
> + * the problem with XQuery is, that it doesn't
> support
> + * any block fetching, so we need to always
> fetch
> + * everything at once. For that reason, the
> cache size
> + * is here set to the tuplecount, such that we
> do a full
> + * fetch at once. To avoid a division by zero
> lateron,
> + * we make sure the cache size is not 0 */
> + cacheSize = lang == LANG_SQL ?
> MonetConnection.DEF_FETCHSIZE : (tuplecount + 1);
> cacheSizeSetExplicitly = false;
> } else {
> cacheSize = parent.cachesize;
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Monetdb-checkins mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
>
>
--
| Dr. Stefan Manegold | mailto:[EMAIL PROTECTED] |
| CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ |
| 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 |
| The Netherlands | Fax : +31 (20) 592-4312 |
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers
