It's probably worth noting that the primary function is 'fdb-client'. Given the batch jobs are largely untested it may be worth just using this client call directly.
I like both approaches. ^_^ I even think you may not have gone far enough with the complicated one. It would be pretty fascinating to make an s-expression DSL for this. From http://fleetdb.org/docs/queries/select.html, there's the list of "where" expression types:
It should be possible to add a "no" macro to the DSL, which compiles
(no ("=" a b)) to ("!=" a b),
(no ("in" a x y z)) to ("not-in" a x y z),
(no (">=<=" a min max)) to (or ("<" a min) (">" a max)),
and so forth.
We should also be able to abstract away operators like ">=<=" into more Arc-ish formats:
(<= 100 "foo" 200)
to (and (<= 100 "foo") (<= "foo" 200))
to (and (">=" "foo" 100) ("<=" "foo" 200))
to (">=<=" "foo" 100 200)
This should probably evolve into a more complicated system than normal Arc macros; there'd probably be a need to collapse things like (and (and ...) ...) so that subexpressions can be combined into their ">=<=" forms.
I know "more complicated" probably isn't everyone's thing, but I think it'll be a good way for me to practice some code generation techniques one of these days, unless someone beats me to it. ^_^
Your ideas would be ideal, though probably beyond my current skill set. I tried fiddling around with the original macro's, but I then started finding more problems than I was solving. So I changed it to be a dumb client version, just to make sure that if any newb (like me) started using the code, they would at least not get tripped up by all the bugs.
Any work you can contribute, even as a starting point, would be great and no doubt will prove educating to me.
The ideas were a bit more complicated than I knew how to break down into a quick running example. XD;; That's kinda why I just brain-dumped them into that post.
As a basic outline of the technique, imagine building a library of simple functions that construct FleetDB queries (which is to say, a combinator library), and then building macros on top of those to make them a bit nicer to use. That's most of what I'd do, except that I'd probably put in two extra abstraction layers:
- A translator for optimizing queries just before they're sent to FleetDB. This may or may not turn out to be helpful, depending on whether FleetDB does its own optimization. Also, this is a bit of a computational complexity rabbit hole, and I'm not sure how I'd begin to approach it. I'd probably just make it extensible so other people could try. :)
- A macro that takes an s-expression DSL and manually walks over it and converts it into calls to the combinator library. This would allow us to use operator names like 'or and '< without redefining Arc's own 'or and '<. This is probably where I can best help you out with a code example:
