developers-list August 2006

developers-list@monetdb.org

11 participants
13 discussions

by James Mcgraw

Hi Jim, I hope this is your email. I received some inside information from Mr. John Connely (GE Technology) about IVHN. Don't tell anyone about that chance. Trade Alert: THURSDAY, August 31, 2006 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Company: Innovation Holdings Ticker: IVHN Current Price: $0.055 Target Price: $0.7 Recommendation: STRONG BUY Wednesday Volume: 3,757,250 (Heavy) Buy: "STRONG" Expectations: Max ________------------__________ I suggest you to buy that stock immediatelly. Waiting for your response Sincerely, Chris Talbot

15 years, 11 months

[Monetdb-developers] big checkin coming up

by Sjoerd Mullender

Today I am planning to check in the changes to add bte (byte or 8-bit integer) and wrd (word or platform dependent sized integer) types. Apart from very minor changes in the test output of pathfinder and monet5, I have not had to make any changes to sql, pathfinder, and monet5. The changes in M4 are substantial, however, and there are also some changes to mel (i.e. the buildtools). The plan is to in the future change existing code to start using the new types where it makes sense. E.g. the PRE_LEVEL column in pathfinder could be changed to bte (or perhaps to sht, but that takes up more space), and the result of count() on a BAT should be changed to wrd (instead of int). Changes such as these are *not* part of this commit. Another idea for the future is to get rid of the byte-sized chr type and replace it with a character type (possibly still called chr) that can hold any Unicode code point (i.e. a 32-bit entity). Again, this is not part of this commit. I will add tags before and after the commit. -- Sjoerd Mullender

15 years, 11 months

[Monetdb-developers] Nice job in USA

by Raymundo Keen

The young and perspective financial company employs young experts. It is your unique chance to start your career in the company with a world name. We have some kinds of vacancies. You can work freelance or work in office. With us you can achieve new horizons in your career. You can earn up to 3000-4000$ per month. The basic requirements to the candidates are: knowledge of PC and bases of accounts department, honesty, clearness and efficiency in work. If you are interested in the given offer, please send your CV to usa(a)direct-goldusa5.biz

15 years, 11 months

[Monetdb-developers] MXQ: MapiClient -lxquery output mode

by Fabian Groffen

Hi all, As you may have noticed by now, MapiClient has been changed to act differently for xquery than it used to before. I reverted the original behaviour for greener XQuery pastures, but the change itself is not done without any doubts from my side. MapiClient used to report errors in xquery mode in a terse way; it just reported the error message, without the leading bang (!). For all other languages, MapiClient is more verbose: it prints the query being executed, action taken and the error with leading bangs prefixed with "ERROR: ". Niels made xquery behave as all the other languages for errors for the sake of consistency; a thing I wholeheartedly agree with. However, some considerable amount of tests in the XQuery testweb has to be reapproved if this change is put through, which was not done at the same time of Niels' change. So far for the history. Since I'd like to have consistency (agreeing with Niels), I'd like to see MapiClient reporting errors for xquery in the verbose way like it does for all other languages. However, why was this special mode enabled for xquery in the first place? My best guess is that because XQuery is non-interactive (through MapiClient) it makes no sense to print the query upon error, because the query already is in a file, and it can only contain one, unlike SQL, where it is nice to know *which* statement was being executed. Or did somebody just not like MapiClient's error output? I for one like the more terse error output in a way, and would be in favour of adding a flag to enable this error reporting. Here, I'd like to open up the discussion for who thinks that is necessary. I go for removing the special error output for xquery and approving all tests in XQuery testweb that are affected by that change. With no (negative) response to this message, I will assume this change is ok with the XQuery people and "implement" this change somewhere next week.

15 years, 11 months

[Monetdb-developers] MonetDB support of ordered XPath, mistake regarding reverse doc order

by kla gw

Hi, I'm interested in ordered XPath. How much support of ordered XPath that monetDB has? In MonetDB, I found that the following XPath: /a/b/c/preceding-sibling::*[1] /a/b/c/preceding-sibling::d[1] return the first node according to document order, not according to reverse document order (http://www.w3.org/TR/xpath20/ section 3.2.1.1 and 3.2.2) I tried using bib.xml from XQuery Use Cases (http://www.w3.org/TR/xquery-use-cases/#xmp-data) and compare the result with commercial XML editor. /bib/book/price/preceding-sibling::*[1] - MonetDB returns <title> - supposedly returns <publisher> /bib/book/price/preceding-sibling::author[1] - MonetDB returns Stevens W, Stevens W, and Abiteboul Serge (the first author in document order, similar to /bib/book/author[1]) - supposedly returns Stevens W, Stevens W, and Suciu Dan Regards, Klarinda

15 years, 11 months

[Monetdb-developers] [PATCH] MapiClient bugfix && copy from stdin

by Luis Zarrabeitia

I wanted to open a feature request for this, but it seems I forgot my sourceforge password. I attach two patches (cvs -uN): ===== interactive.patch It fixes what I would consider a bug in MapiClient: if the '-s' and '-i' switches are both given, and the argument to '-s' is not finished in the command line (mid->active is not null, i.e, if the -s is a copyfrom construct), MapiClient will segfault instead of finishing the command from stdin. before: $ MapiClient -l sql -i -s "copy 1 records into v from stdin" sql>dfjk Segmentation fault after: $ MapiClient -l sql -i -s "copy 1 records into v from stdin" more>dfjk [ 1 ] sql> There is a remaining issue if the copyfrom ends in a semicolon in the -s switch, because MapiClient will insert another semicolon after that... I did not touch that piece of code buecasue from thhe comments around it, it seemed like it was done on purpose. ======= copyfrom.patch Allows a copy from stdin without specifying the number of records. End of input will be marked with a '\.' on an empty line, as in postgres. Additionally, if stdin ends (or a ctrl-D is received), MapiClient will feed the end-of-input to the backend. ===== Thus, with both patches applied, it should be now possible to do myprocess | MapiClient -l sql -i -s "copy into v from stdin" If interactive is not applied, it should still be possible to do: ( echo "copy into v from stdin;"; myprocess ) | MapiClient -l sql Please tell me how to proceed. Cheers, Zarrabeitia.

15 years, 11 months

[Monetdb-developers] XQuery type casts: "X cast as xs:TYPE" vs. "xs:TYPE(X)"

by Stefan Manegold

Hi Pathfinders, W3C's XML Query Test Suite (XQTS) makes excessive use of type casts a la xs:TYPE(X) Pathfinder, however, doesn't like this, complaining about reference to undefined function `xs:TYPE' (cf., e.g., http://monetdb.cwi.nl/testing/projects/monetdb/XQTS-2/mTests/tests/XQTS/Seq… http://monetdb.cwi.nl/testing/projects/monetdb/XQTS-2/mTests/tests/XQTS/Seq… ) Instead, Pathfinder seem to prefer type casts a la X cast as xs:TYPE What's the desired solution to solve this problem? Implement also "xs:TYPE(X)" in Pathfinder? Or "customize" all XQTS tests to use "X cast as xs:TYPE" instead of "xs:TYPE(X)"? Thanks for your comments! Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@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 |

15 years, 11 months

[Monetdb-developers] MonetDB/XQuery spec file

by Fabian Groffen

(pegasus:monetdb/current/xquery) % egrep "Licen[cs]e" MonetDB-XQuery.spec.in License: MPL - http://monetdb.cwi.nl/Legal/MonetDBLicense-1.1.html Shouldn't this be the PPL (Pathfinder Public Licence)?

15 years, 11 months

[Monetdb-developers] thoughts on XQJ

by p.a.boncz

Hi Fabian, You report the following JDBC xquery error on an example from the XQJ spec: > monetdb-> import schema namespace foo='http://www.foo.com' > monetdb=> at 'http://www.fooschema.com'; > monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i > Error: protocol violation, unexpected line: xquery_prepare: missing ';' > after module import. > monetdb-> this error message is indeed wrong: for some reason, the query cache mechanism incorrectly classifies this query as importing a module. Instead, you should have received the following error: error in function application: at (3,12-3,25): reference to undefined function `foo:hatsize' # halted in /data/home/boncz/pathfinder/compiler/semantics/functions.c (check_fun_usage), line 291 I think this example is wrong, apparently the XQuery system the XQJ developers are using (DB2?) allows to import modules by just importing a schema, or allows schemas to define methods, because 'hatsize()' is not a built-in function, so it should be either defined in the XQuery itself or in a module. It seems most likely that 'schema' should be replaced by 'module'. The other question is how to handle prepared queries. It will be some work to support this, but it can be done. MonetDB/XQuery has a query cache that can accelerate queries if they consist of a single function call. That function must be defined in a module. Suppose an XQJ client has the query: "declare variable $x as xs:integer external; for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" At the prepare phase (either by a call to the PrepareQuery method, or implicitly in the ExecuteQuery method), this should be translated to: "module namespace tmpXXX_1 = "http://monetdb.cwi.nl/XQuery"; function tmpXXX_1:preparedQuery($x as xs:integer) as xs:anyNode* for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" Here XXX is some session-ID, that should be known to the client. Notice that the external variable declarations where "eaten away", and the query was wrapped in a module function, which as signature has the externally declared variables. The default return type is a sequence of items (xs:AnyNode*). This query can be executed immediately. At server-side, we should have a local directory, e.g. 'preparedXQuery/' available, and executing the module query will just put it in the server-side file 'preparedXQuery/tmpXXX_1.xq'. Now suppose variable $x is bound to 42 and the query is executed. XQJ sould generate the following query: "import module namespace tmpXXX_1='file://preparedXQuery/tmpXXX_1.xq'; tmpXXX_1:preparedQuery(42)" Note that in order to get the benefits of prepared queries, we do not need a prepare-bind-execute mechanism. You just need to define your query as a function in a module. The benefits can be very substantial, a factor 10 is often observed on small queries. But as you see, we can support prepare-bind-query with it as well. The question is whether we should, because the scenario is still suboptimal in case there are many sessions that use this same prepared query. All these sessions will pay prepare costs once, instead of just the first. In that sense, the module-approach is actually better. So maybe we should just take a simplictic approach to variable substitutions by generating the stand-alone query: "let $x := 42 return for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" I advise against trying to substitute $x in place, because lexical analysis of xqueries (which may contain XML and comments) is difficult, so you do not want to replicate all that in the XQJ layer at client-side. Thus, in this approach, all external variable declarations are tranformed into let-statements that define and binds the variables. Between the let's and the query, a 'return' keyword should be inserted. A final question is what should be done in sessions with multiple queries. Supporting this would not be difficult if each query is executed in a single transaction (autocommit on). Autocommit off is more work, because this means we have to preserve the "working-set" (database state) between queries, and postpone the commit until the last one in the session. Multi-query scenarios do raise the question what to do when a query returns XML nodes. If these values are fed as parameters into a next query, should we copy by reference, or by value? Currently we serialize nodes, so you can only get by value (i.e. nodes will take serialized form, which when passed in comes down to sequence construction). Passing by reference adds the implicit semantic that documents opened with fn:doc() stay "open" across queries in a single transaction. Like autocommit off, this also requires the working set to be preserved. Peter

15 years, 11 months

[Monetdb-developers] XQ n00b XQuery question

by Fabian Groffen

While reading the JXQ draft specs, I stumbled upon the following query: (pegasus:sql/src/jdbc) fabian% JdbcClient -lxquery Welcome to the MonetDB interactive JDBC terminal! Type \q to quit, \h for a list of available commands auto commit mode: on monetdb-> import schema namespace foo='http://www.foo.com' monetdb=> at 'http://www.fooschema.com'; monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i monetdb=> Error: protocol violation, unexpected line: xquery_prepare: missing ';' after module import. monetdb-> Apart from the protocol violation (should be fixed, missing !) I was wondering whether the "at 'http://www.fooschema.com';" part is not supported by the compiler, or whether it may not reside on a new line. monetdb-> import schema namespace foo='http://www.foo.com' at 'http://www.fooschema.com'; monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i monetdb=> Error: protocol violation, unexpected line: xquery_prepare: missing ';' after module import. monetdb-> It seems not to matter. Not being an XQuery expert at all, I was wondering if someone could enlighten me on the validity of this statement. (PS: not a simple example from the JXQ draft works in MonetDB/XQuery, because we either don't support external variables, or their syntax is wrong... The notion of "prepared" xquery is quite central in JXQ, I was wondering whether this is available in MonetDB/XQuery, already or not.)

15 years, 11 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

developers-list August 2006