Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback #2

Open
ChristianGruen opened this issue Nov 9, 2015 · 4 comments
Open

Feedback #2

ChristianGruen opened this issue Nov 9, 2015 · 4 comments

Comments

@ChristianGruen
Copy link

Hi Andy, I finally had some time to look at your project (actually, I did do so two weeks ago). I haven’t completely thought it through, but I also believe that the only chance to have real asynchronous queries is to create a completely new query process, and (as long as there is no way to serialize XQuery expressions) to pass the query on as string.

I could possibly add a new xquery:fork($func as xs:string) as empty-sequence() function in BaseX, which does exactly that (the query could be both updating or non-updating). As you are actually doing more than this, I’ll spend some more time on this before implementing anything by myself… Thanks!

@ChristianGruen
Copy link
Author

Btw: As we can always use try/catch in a query, I am not sure if we really need then/fail branches. Of course it may happen that a query cannot be evaluated at all, but this usually happens if a query contains parsing errors, which can be fixed in advance.

@james-jw
Copy link

I think the xquery:fork-eval function you propose would be great.

I often find executing refined xquery expressions within the context of a larger expression garners way better performance. For example see xq-hunt.

Being able to fork that evaluation, including updates would be great.

In regards to try/catch... then/fail is not the same as its more dynamic in nature, allowing for conditional try/catch logic which in the context of certain applications, such as meta programming is highly desirable.

@apb2006
Copy link
Member

apb2006 commented Nov 10, 2015

Thanks for the comments.

I would see something like xquery:fork($func as xs:string,$opts as map(*)) as xs:string
where the return would be some sort of handle to the task, for cancelling etc.

@ChristianGruen
Copy link
Author

I would see something like xquery:fork($func as xs:string,$opts as map(*)) as xs:string
where the return would be some sort of handle to the task, for cancelling etc.

Sounds reasonable. Ideally, such a thread id could then also be utilized to fetch a cached result. We’d additionally need to decide how long results will be cached before they are invalidated, etc.

I’ve added some more thoughts in BaseXdb/basex#1211.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants