[Monetdb-developers] [Monetdb-checkins] java/src/nl/cwi/monetdb/jdbc MonetConnection.java, , 1.2, 1.3

Stefan Manegold Stefan.Manegold at cwi.nl
Wed Feb 20 21:07:48 CET 2008


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
> Monetdb-checkins at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
> 
> 

-- 
| Dr. Stefan Manegold | mailto:Stefan.Manegold at cwi.nl |
| 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       |




More information about the developers-list mailing list