wcandillon / xqlint

JSONiq & XQuery Quality Checker
Apache License 2.0
52 stars 22 forks source link

update insert #57

Open JonathanRowell opened 8 years ago

JonathanRowell commented 8 years ago

I don't know whether you implemented update insert (eXist style syntax) but I'm getting an error "lexical analysis failed while expecting 'instance' at the word "into" in the following bit of XQuery :+1:

return update insert into doc($transit-uri)/transit:root

regards Jonathan

wcandillon commented 8 years ago

@JonathanRowell I have the feature ready for testing at #48 . Do you want to send me files I can play with? Also, I would recommend to switch to the official XQuery updating syntax that exist-db should support by now I believe. So in that sense it might be good that these expressions are not handled by xqlint.

JonathanRowell commented 8 years ago

Thanks. eXide supports the offical syntax in Realse Candiate 3.0. I'm currently using the stable version 2.2 I was planning to switch later in the year after I'd got all this linting, testing and packaging sorted out. (Continuous integration here!)

If it is too much trouble I'll use --force on the build to ignore the error. The files will get uploaded to eXist during the test phase before packaging.

The file is rather large. Here is a smaller one

xquery version "3.0";

module namespace bibtrigg = "http://www.bibdia.de/namespaces/elastic-trigger";

declare namespace trigger = "http://exist-db.org/xquery/trigger"; declare namespace xmldb = "http://exist-db.org/xquery/xmldb";

(: Bibdia namespaces :) declare namespace transit = "http://www.bibdia.de/namespaces/elastictransit";

declare variable $collection external;

(: Put the change into the elastic transit collection :) declare function bibtrigg:makeTransitEntry($uri as xs:string, $collection as xs:string, $action as xs:string) { let $transit-collection := "/db/apps/bibdia-databases/elastic" let $transitDoc := concat($collection,'.xml') let $transit-uri := concat($transit-collection,'/',$transitDoc) let $myDate := current-dateTime() (: create the transit file if it does not exist :) let $transitFile := if (not(doc-available($transit-uri))) then xmldb:store($transit-collection, $transitDoc, <transit:root/>) else () (: update the relevant file :) return update insert <transit:index name="{$id}" action="{$action}" date="{$myDate}" /> into doc($transit-uri)/transit:root };

(: Lots of other functions :)

joewiz commented 8 years ago

AFAIK eXist's XQuery Update syntax hasn't changed between 2.2 and 3.0RC. @wolfgangmm could shed light on this and may already have some support for eXist-style update syntax in his branch of xqlint imported in eXide.

wcandillon commented 8 years ago

@joewiz I would be great if someone from the existdb community could look at my PR and most importantly contribute tests for exist-db.

JonathanRowell commented 8 years ago

I was under the impression, Joe, that RC3.0 would support XQuery Update Facility (https://www.w3.org/TR/xquery-update-10/). If it doesn't then one would need even more that xqlint supported the old style.

joewiz commented 7 years ago

Sorry @wcandillon I missed your reply. I noticed that @apb2006 had an eXist related commit at https://github.com/wcandillon/xqlint/pull/67. Is there anything I can help with or try to entice folks in the eXist community to help with? I think @wolfgangmm had a fork of xqlint with support for eXist XQuery syntax, used in eXide and existdb-atom: https://github.com/eXistSolutions/xqlint. But I'm not quite sure the status of either the original xqlint or the fork, or what is needed.

joewiz commented 7 years ago

@JonathanRowell No work has been done on supporting the final XQuery Update spec in eXist. My understanding is that it would be quite a significant undertaking because the model from the draft implemented in eXist changed quite a bit. Thus, both coding syntax and logic in applications written against the eXist XQuery Update syntax would need to be modified a lot. While I would like to see the spec supported, particularly for in-memory updates, this is my understanding of how things stand.

apb2006 commented 7 years ago

@wcandillon and @joewiz my pull request was in error. I was trying to pull within branches in my fork and got the direction wrong (again). Sorry for any confusion.

I do think xqlint is a great piece of work and I am trying to add features to support BaseX in my fork. One part of this is the XQuery 3.1 grammar support. I borrowed @wolfgangmm's map support from eXist for part of this, there are also later additions like => Another part is additions to static_context.js.

It would be great if ultimately these could all be merged together.

joewiz commented 7 years ago

@wcandillon You asked for a volunteer from the eXist community, and I think I'd like to take a crack at it. It was very kind of you to begin work on this, and I can see how this would really help eXist-db users, who now make use of xqlint in eXide, atom-existdb, and in their own grunt-based build and deploy pipelines. I notice the PR is a little out of sync with the current master, or at least couldn't be merged as is. How would you like me to proceed? Shall I just start from the existdb branch here and bring it up to date, or would you like to update it or do anything else before I begin?

joewiz commented 7 years ago

Some questions I can anticipate now: How can I activate the ExistParser when I call xqlint? Also, to what extent is the XQueryParse up to date with XQuery 3.1? I see some things there, like JSONTest, which don't quite look familiar.

wcandillon commented 7 years ago

@joewiz I am so excited to have you on board. The current XQuery parser is Zorba (with JSONiq, Scripting and so on), this is why the syntax doesn't look so familiar. The conflict on the Existdb branch seems to be only on package.json so it shouldn't be too hard to solve. I think you should be able to dive in very easily. Let me know if you have any questions. Worst case scenario we can have a google hangout next week to discuss things.

joewiz commented 7 years ago

Great, I'll dig in and see what my questions are. My only question for now is how to select the eXist parser? It appears that xqlint uses file extensions to tell whether to select the XQuery vs JSONiq parsers. For eXist there isn't a readily sniffable hook - no eXist-specific file extension or version string. I couldn't see a flag for selecting a parser.

apb2006 commented 7 years ago

Some thoughts on this ... I am working of a BaseX variant https://github.com/Quodatum/xqlint/tree/basex. I just updated XQueryParser.ebnf with some XQuery 3.1 grammar features - XQuery update is supported by BaseX. This means I do not need to "select" it. However I found to make this useful I needed to add information about the BaseX static context - namespaces, modules etc to https://github.com/Quodatum/xqlint/blob/54b6c23241749bc449025be27cc7d035d83267a8/lib/compiler/static_context.js

I wonder if some kind of "xquery profile" mechanism might be useful here. So one could build versions of xqlint with parser and context only for say Zorba 3.0 or Marklogic ver X etc.
Is there a recommended approach here?

/Andy

bmix commented 6 years ago

+1 for all things BaseX ;) 👍