At Fri, 29 Aug 2014 08:33:13 +0200, Stephan Beal wrote: > > [1 <multipart/alternative (7bit)>] > [1.1 <text/plain; UTF-8 (7bit)>] > > [1.2 <text/html; UTF-8 (quoted-printable)>] > On Fri, Aug 29, 2014 at 4:59 AM, Timothy Beyer <bey...@fastmail.net> wrote: > > There are some limitations that we worked around, such as the fact that > the "%" > symbol has a lot of bugs when used in JSON SQL queries (thus making most > wildcard matches with LIKE useless), so I use GLOB with a regular > expression > for case-insensitivity. > > If you can post some examples i'd be happy to take a look at fixing them. >
Hi Stephan, Sorry about the delayed response. I'll get specific queries that failed next week, but as a summary, queries like the following have issues in JSON URLs: foo LIKE '%BAR%' I believe that there is some sort of issue with the way the % symbol is handled. Whereas the following works correctly: foo GLOB '*[Bb][Aa][Rr]*' I've been meaning to submit patches, but I haven't even looked at that part of the code yet, and you probably know it much better than I do. Thanks for the JSON API, it's been invaluable. > th1 is extremely limited. libfossil is developing more powerful script > bindings: > > https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view That sounds very promising. My issues with TH1 were namely that I didn't know how to use it in dynamic AJAX type applications, (to start with, I think the TH1 argv API was deprecated, am I correct in this assumption?) and that I couldn't access parts of the database that were crucial to my needs. I'll look into libfossil at some point, as I find fossil the ideal basis for applications based on a versioned datastore. I like TCL and especially TK, so I see a lot of potential in TH1, but it seems to me that JavaScript is already an ideal extension language for most fossil-based web applications. > Those permssions are for a reason - imagine what happens if a user sends > "DROP TABLE blob" via the > JSON API. Even if we use authenticators which prohibit that (sqlite supports > it), being able to query > allows them to reach _any_ blob, regardless of access restrictions. I figured that was the reason, and it's perfectly legitimate, but I just wish that there was some way to block all JSON API URLs from outside of the fossil repository, only allowing it to be used in the application itself. Regards, Tim _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
