Re: [Monetdb-developers] Monetdb-developers Digest, Vol 5, Issue 19
Yes, a string return type. Hey, it is an identifier ("node identifier"), that sounds more like a string than an integer anyway. And you then you can do id(nid($elt)), i.e. these functions are each others inverse.
van: monetdb-developers-request@lists.sourceforge.net datum: 2006/10/26 Thu PM 09:22:27 CEST aan: monetdb-developers@lists.sourceforge.net onderwerp: Monetdb-developers Digest, Vol 5, Issue 19
Send Monetdb-developers mailing list submissions to monetdb-developers@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/monetdb-developers or, via email, send a message with subject or body 'help' to monetdb-developers-request@lists.sourceforge.net
You can reach the person managing the list at monetdb-developers-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of Monetdb-developers digest..."
Today's Topics:
1. Re: [Monetdb-pf-checkins] pathfinder/compiler/semantics xquery_fo.c, 1.83, 1.84 (Jan Rittinger) 2. Upcoming changes in the type system affect existing code! (Jens Teubner)
----------------------------------------------------------------------
Message: 1 Date: Thu, 26 Oct 2006 17:19:24 +0200 From: Jan Rittinger
Subject: Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/semantics xquery_fo.c, 1.83, 1.84 To: monetdb-developers@lists.sourceforge.net Message-ID: <4540D1FC.5050604@in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Do you really mean string as return type of fn:nid?
On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions:
Update of /cvsroot/monetdb/pathfinder/compiler/semantics In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/compiler/semantics
Modified Files: xquery_fo.c Log Message: fast NID node retriveal by NID - moved support for id/idref node retrieval into pathfinder.mx having this as an API function will allow us to provide this functionality using indices later (i.e. be able to lock and isolte a hash index). it also helps a port of this functionality to algebra.
for the moment, there are no shared hash tables, and ID/IDREF queries on updatable XML documents will be slowish (sequential scans needed) the new NID access is a good alternative to look up nodes.
- implemented in ID node retrieval support for string sthat are numbers, these are interpreted as NIDs, not ID attributes.
- implemented a new fn:nid(element()*) as xs:string* builtin function that returns the NIDs of element nodes.
- fixed some constant support things (mposjoin)
Index: xquery_fo.c =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/semantics/xquery_fo.c,v retrieving revision 1.83 retrieving revision 1.84 diff -u -d -r1.83 -r1.84 --- xquery_fo.c 19 Oct 2006 19:32:27 -0000 1.83 +++ xquery_fo.c 26 Oct 2006 12:12:40 -0000 1.84 @@ -184,6 +184,11 @@ .par_ty = (PFty_t[]) { PFty_opt (PFty_xs_string ()) }, .ret_ty = PFty_opt (PFty_doc (PFty_xs_anyNode ())) } }, .alg = PFbui_fn_doc } + , /* fn:idref (xs:element) as integer */ + { .ns = PFns_fn, .loc = "nid", + .arity = 1, .sig_count = 1, .sigs = { { + .par_ty = (PFty_t[]) { PFty_xs_anyElement () }, + .ret_ty = PFty_xs_string () } } } , /* fn:id (string*) as element* */ { .ns = PFns_fn, .loc = "id", .arity = 1, .sig_count = 1, .sigs = { {
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Monetdb-pf-checkins mailing list Monetdb-pf-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
-- Jan Rittinger Database Systems Technische Universit?t M?nchen (Germany) http://www-db.in.tum.de/~rittinge/
------------------------------
Message: 2 Date: Thu, 26 Oct 2006 16:43:14 +0200 From: Jens Teubner
Subject: [Monetdb-developers] Upcoming changes in the type system affect existing code! To: monetdb-developers@lists.sourceforge.net Message-ID: <20061026144314.GD11690@notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii Pathfinder folks,
I am currently busy rewriting Pathfinder's type system. In the short-term view, this rewrite will bring us a much cleaner and more consistent representation of types, and I'm quite confident that there will be less bugs in the new code; I have actually found quite a few in the existing code while doing the rewrite.
Most importantly, however, on a longer term view, my rewrites pave the ground to implement also *dynamic* typing in Pathfinder in an elegant and standards-compliant manner.
The rewrite will also change the internal representation of types in Pathfinder. Most of the current built-in primitive types will become *named* types, in line with the XQuery specs. Most importantly, this makes Pathfinder highly flexible and easily extendible with respect to types.
Unfortunately, there's a bunch of code flying around in the project that inspects the (current) internal type representation in a deprecated manner. My changes *will* break such code. This mainly affects code that looks into the enum field PFty_t.type, a field that is not (and has never been) supposed to be inspected by code outside types.c and subtyping.c. milprint_summer.c in particular is full of such references. ONCE I'M DONE WITH MY REWRITES, SUCH CODE *WILL* BREAK.
MY NEXT CHECKIN WILL TAG AFFECTED CODE IN MILPRINT_SUMMER.C WITH #ifdef'S. WHOEVER FEELS RESPONSIBLE FOR THIS ABUSE OF THE CURRENT TYPE REPRESENTATION OR WANTS TO RESCUE THE CODE IN milprint_summer.c FROM DYING CAN USE THESE #ifdef'S TO FIND THE APPROPRIATE PLACES AND FIX THE RESPECTIVE CODE. I WILL *NOT* FIX THE AFFECTED CODE MYSELF.
The "official" way to inspect Pathfinder's types is to use the functions provided by types.c and subtyping.c. The subtype check PFty_subtype() is the function that allows most of the checks against types that one ever needs. Additional helpers can be PFty_prime() (which normalizes a structured type to have the form `t1 | t2 | t3 | ...') or PFty_quantifier() (determining the quantifier, `0', `1', `?', `+', or `*', of a given type).
The test whether a type t is the type `xs:string' may, e.g., implemented by testing
PFty_subtype (t, PFty_xs_string ()).
(Some care has to be taken, though, that this is a *subtype* relationship. Often, this is what you actually need. If you want to test for type *equivalence*, use PFty_equality(), which applies the subtype test in both directions.)
Quantifiers are usually tested with a subtype test against a regular expression over the `item' type.
PFty_subtype (t, PFty_item ()),
e.g., tests whether the quantifier of t is exactly one.
You may want to look into other pieces of our code, e.g., core2alg.brg, to see how PFty_subtype() and others can be used to test types. Just watch out for invocations of PFty_subtype().
If you need any further assistance regarding types, just contact me.
Jens
-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263
Unix is user friendly - it's just picky about it's friends.
------------------------------
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------
_______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
End of Monetdb-developers Digest, Vol 5, Issue 19 *************************************************
participants (1)
-
p.a.boncz@chello.nl